After freeing up the rows at the end of the table so it is eligible for truncation, then running a manual VACUUM to actually release the space, I kept running into the problem that the truncation scan was consistently suspended and then aborted due to a conflicting lock requested/held.
But the perversity is that that conflicting lock request can only be coming, as far as I can tell, from the autovac process. I'm not sure how this happens, as I thought autovac never waited for locks but only obtained one if it were instantaneously available, but that it is the only explanation I can think of. I'm not seeing this in 9.4, but I'm not sure how deterministic it is so maybe that is just luck. On an otherwise idle system: pgbench -i -s 1000 -n alter table pgbench_accounts drop CONSTRAINT pgbench_accounts_pkey ; delete from pgbench_accounts; vacuum verbose pgbench_accounts; As soon as truncation scan starts, it suspends and then quickly terminates. Anyone have theories on what's going on? Cheers, Jeff
