Re: Lock problem with autovacuum truncating heap - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Lock problem with autovacuum truncating heap
Date
Msg-id 17960.1301279307@sss.pgh.pa.us
Whole thread Raw
In response to Re: Lock problem with autovacuum truncating heap  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Sun, Mar 27, 2011 at 3:25 PM, Jan Wieck <JanWieck@yahoo.com> wrote:
>> Since we are talking about stable releases, I think just releasing and
>> reacquiring the exclusive lock is enough. We can then try to further improve
>> things for future releases.

> That seems unsafe - things can change under you while you don't hold the lock...

And more to the point, it wouldn't actually fix anything, unless you
chop things up so finely that autovac is never holding the lock for more
than milliseconds.  (I believe it wouldn't even be enough if you could
guarantee that autovac didn't hold the lock for more than
deadlock_timeout, because some other process could reach the timeout and
run the deadlock detector very shortly after autovac acquires its lock.)

I don't believe that *any* of what's being discussed here is suitable
material for back-patching.  And it's not material for 9.1, either.
The time for rewriting VACUUM for 9.1 was three months ago.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Lock problem with autovacuum truncating heap
Next
From: Tom Lane
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Fix plpgsql to release SPI plans when a function or DO block is