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;
+			}
 		}
 	}
 

Reply via email to