Re: autovacuum truncate exclusive lock round two - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: autovacuum truncate exclusive lock round two
Date
Msg-id 20121025022214.GA5162@tamriel.snowman.net
Whole thread Raw
In response to autovacuum truncate exclusive lock round two  (Jan Wieck <JanWieck@Yahoo.com>)
List pgsql-hackers
Jan,

* Jan Wieck (JanWieck@Yahoo.com) wrote:
> This problem has been discussed before. Those familiar with the
> subject please skip the next paragraph.

Apologies if this was already thought-of and ruled out for some reason,
but...

> Because all the scanning had been done in parallel to normal DB
> activity, it needs to verify that all those blocks are still empty.

Would it be possible to use the FSM to figure out if things have changed
since the last scan..?  Does that scan update the FSM, which would then
be updated by another backend in the event that it decided to write
something there?  Or do we consider the FSM to be completely
untrustworthy wrt this (and if so, I don't suppose there's any hope to
using the visibility map...)?

The notion of having to double-scan and the AccessExclusiveLock on the
relation are telling me this work-around, while completely possible,
isn't exactly ideal...

Perhaps another option would be a page-level or something which is
larger than per-row (strikes me as a lot of overhead for this and it's
not clear how we'd do it), but less than an entire relation, but there
are certainly pain points there too.
Thanks,
    Stephen

pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: [WIP] Performance Improvement by reducing WAL for Update Operation
Next
From: Alvaro Herrera
Date:
Subject: Re: enhanced error fields