vac truncation scan problems - Mailing list pgsql-hackers

From Jeff Janes
Subject vac truncation scan problems
Date
Msg-id CAMkU=1zwe5Upk16gagT-sSJW_tB_g27sM46Vy7=4dVKLz2wG8g@mail.gmail.com
Whole thread Raw
Responses Re: vac truncation scan problems
List pgsql-hackers
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

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Relation extension scalability
Next
From: Kyotaro HORIGUCHI
Date:
Subject: GUC context information in the document.