vac truncation scan problems

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: vac truncation scan problems
Date: 2015-03-31 03:54:26
Message-ID: CAMkU=1zwe5Upk16gagT-sSJW_tB_g27sM46Vy7=4dVKLz2wG8g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro HORIGUCHI 2015-03-31 04:02:56 GUC context information in the document.
Previous Message Amit Kapila 2015-03-31 03:48:06 Re: Relation extension scalability