Hi, If pg_dump starts while REPACK (CONCURRENTLY) is waiting for its final lock on a table, it dumps that table with no rows, and still exits successfully:
CREATE TABLE dumptest (id int PRIMARY KEY, v text); INSERT INTO dumptest SELECT x, 'row' || x FROM generate_series(1,1000) x; Session 1: BEGIN; SELECT count(*) FROM dumptest; Session 2: REPACK (CONCURRENTLY) dumptest; -- waits for session 1 Terminal: pg_dump -t dumptest --data-only -- waits behind REPACK Session 1: COMMIT; The dump then contains: COPY public.dumptest (id, v) FROM stdin; \. Using VACUUM FULL or plain REPACK in session 2 instead dumps all 1000 rows. I realise REPACK (CONCURRENTLY) is documented as not being MVCC-safe, and this is just demonstrating that, but the pg_dump docs don't mention it, and as REPACK (CONCURRENTLY) is intended to be run while the database is in use, it seems quite likely to coincide with a backup at some point, and nothing indicates that the backup is missing the table's data. Should this at least be documented on the pg_dump page, or could pg_dump detect that a table has been rewritten since its snapshot was taken and fail instead? Regards Thom
