Wrong return code in vacuumdb when multiple jobs are used - Mailing list pgsql-hackers

From Julien Rouhaud
Subject Wrong return code in vacuumdb when multiple jobs are used
Date
Msg-id CAOBaU_ZuTwz7CtqLYJ1Ouuh272bTQPLN8b1bAPk0bCBm4PDMTQ@mail.gmail.com
Whole thread Raw
Responses Re: Wrong return code in vacuumdb when multiple jobs are used  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
Hi,

While reading vacuumdb code, I just noticed that it can return 0 if an
error happen when -j is used, if errors happen on the last batch of
commands.

For instance:
session 1
alter database postgres set lock_timeout = 1;
begin;
lock table pg_extension;

session 2
$ vacuumdb -d postgres -t pg_extension -t pg_extension
vacuumdb: vacuuming database "postgres"
vacuumdb: error: vacuuming of table "pg_catalog.pg_extension" in
database "postgres" failed: ERROR:  canceling statement due to lock
timeout

$ echo $?
1

$ vacuumdb -d postgres -t pg_extension -t pg_extension -j2
vacuumdb: vacuuming database "postgres"
vacuumdb: error: vacuuming of database "postgres" failed: ERROR:
canceling statement due to lock timeout

$ echo $?
0

but

$ vacuumdb -d postgres -t pg_extension -t pg_extension -t pg_extension -j2
vacuumdb: vacuuming database "postgres"
vacuumdb: error: vacuuming of database "postgres" failed: ERROR:
canceling statement due to lock timeout

$ echo $?
1

This behavior exists since 9.5.  Trivial patch attached.  I'm not sure
that a TAP test is required here, so I didn't add one.  I'll be happy
to do so though if needed.

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: compiler warning in pgcrypto imath.c
Next
From: Michael Paquier
Date:
Subject: Re: First-draft release notes for back branches are up