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.
diff --git a/src/bin/scripts/vacuumdb.c b/src/bin/scripts/vacuumdb.c index f15e1ad8f1..e9da74c3ba 100644 --- a/src/bin/scripts/vacuumdb.c +++ b/src/bin/scripts/vacuumdb.c @@ -712,7 +712,10 @@ vacuum_one_database(const char *dbname, vacuumingOptions *vacopts, for (j = 0; j < concurrentCons; j++) { if (!GetQueryResult((slots + j)->connection, progname)) + { + failed = true; goto finish; + } } }