View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0000923 | bareos-core | director | public | 2018-03-02 16:34 | 2023-03-21 09:11 |
Reporter | kjetilho | Assigned To | bruno-at-bareos | ||
Priority | normal | Severity | major | Reproducibility | always |
Status | closed | Resolution | reopened | ||
Platform | Linux | OS | any | OS Version | 3 |
Product Version | 16.2.7 | ||||
Summary | 0000923: sql_query retry hides real error | ||||
Description | I was getting a puzzling error: 'INSERT INTO Filename (Name) SELECT a.Name FROM (SELECT DISTINCT Name FROM batch) as a WHERE NOT EXISTS (SELECT Name FROM Filename WHERE Name = a.Name)' this failed with ERR=ERROR: relation "batch" does not exist The *actual* error did not become apparent before I turned on logging in PostgreSQL: LOG: statement: INSERT INTO Filename (Name) SELECT a.Name FROM (SELECT DISTINCT Name FROM batch) as a WHERE NOT EXISTS (SELECT Name FROM Filen ame WHERE Name = a.Name) ERROR: integer out of range STATEMENT: INSERT INTO Filename (Name) SELECT a.Name FROM (SELECT DISTINCT Name FROM batch) as a WHERE NOT EXISTS (SELECT Name FROM Filename W HERE Name = a.Name) LOG: statement: SET datestyle TO 'ISO, YMD' LOG: statement: SET cursor_tuple_fraction=1 LOG: statement: SET standard_conforming_strings=on LOG: statement: INSERT INTO Filename (Name) SELECT a.Name FROM (SELECT DISTINCT Name FROM batch) as a WHERE NOT EXISTS (SELECT Name FROM Filen ame WHERE Name = a.Name) ERROR: relation "batch" does not exist at character 75 in other words, the root cause was that filenameid now needs to be bigger than integer on my system. that exact problem has obviously been fixed in Bareos 17, but the retry logic may need a closer look anyway. | ||||
Steps To Reproduce | bump up filenameid sequence, do a backup jobs with spooled attributes. | ||||
Additional Information | here's the log from 16.2.6. the logic is the same in 16.2.7 as far as I can tell: 02-Mar-2018 15:29:53.283258 dump-dir (500): postgresql.c:622-2024858 sql_query starts with 'INSERT INTO Filename (Name) SELECT a.Name FROM (SELECT DISTINCT Name FROM batch) as a WHERE NOT EXIS TS (SELECT Name FROM Filename WHERE Name = a.Name)' 02-Mar-2018 15:29:53.274530 dump-dir (50): postgresql.c:665-2024858 Result status fatal: INSERT INTO Filename (Name) SELECT a.Name FROM (SELECT DISTINCT Name FROM batch) as a WHERE NOT EXISTS (SELECT Name FROM Filename WHERE Name = a.Name) 02-Mar-2018 15:29:53.283130 dump-dir (50): postgresql.c:665-2024858 Result status fatal: INSERT INTO Filename (Name) SELECT a.Name FROM (SELECT DISTINCT Name FROM batch) as a WHERE NOT EXISTS (SELECT Name FROM Filename WHERE Name = a.Name) if I had been more eagle-eyed I could have spotted that there are two "Result status fatal", but ... | ||||
Tags | No tags attached. | ||||
Not a bug, you are missing the fact to apply the update_bareos_database script this one will take care of converting all old thing to the newer standard. | |
upgrade_database_script can handle all case | |
You missed the point. See name of ticket, and the last line of the report It is fine that you close it as a wontfix, but it is a general bug with the retry logic. Or was - I have not checked how the code has changed since Bareos 17. |
|
Need new report with recent code. | |
Date Modified | Username | Field | Change |
---|---|---|---|
2018-03-02 16:34 | kjetilho | New Issue | |
2023-03-11 18:00 | bruno-at-bareos | Note Added: 0004908 | |
2023-03-11 18:01 | bruno-at-bareos | Assigned To | => bruno-at-bareos |
2023-03-11 18:01 | bruno-at-bareos | Status | new => resolved |
2023-03-11 18:01 | bruno-at-bareos | Resolution | open => no change required |
2023-03-11 18:01 | bruno-at-bareos | Note Added: 0004909 | |
2023-03-14 11:38 | kjetilho | Status | resolved => new |
2023-03-14 11:38 | kjetilho | Resolution | no change required => reopened |
2023-03-14 11:38 | kjetilho | Note Added: 0004910 | |
2023-03-21 09:11 | bruno-at-bareos | Status | new => closed |
2023-03-21 09:11 | bruno-at-bareos | Note Added: 0004912 |