View Issue Details

IDProjectCategoryView StatusLast Update
0000923bareos-coredirectorpublic2023-03-21 09:11
Reporterkjetilho Assigned Tobruno-at-bareos  
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionreopened 
PlatformLinuxOSanyOS Version3
Product Version16.2.7 
Summary0000923: sql_query retry hides real error
DescriptionI 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 Reproducebump up filenameid sequence, do a backup jobs with spooled attributes.
Additional Informationhere'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 ...
TagsNo tags attached.

Activities

bruno-at-bareos

bruno-at-bareos

2023-03-11 18:00

manager   ~0004908

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.
bruno-at-bareos

bruno-at-bareos

2023-03-11 18:01

manager   ~0004909

upgrade_database_script can handle all case
kjetilho

kjetilho

2023-03-14 11:38

reporter   ~0004910

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.
bruno-at-bareos

bruno-at-bareos

2023-03-21 09:11

manager   ~0004912

Need new report with recent code.

Issue History

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