Обсуждение: CLUSTER vs toast vacuuming: there's still a problem

I thought some more about the bug #5998 business, and I believe there's
still a risk unaddressed by yesterday's patch.  Suppose that we begin
a CLUSTER operation on some table, and then while it's running (perhaps
in the sort stage) autovacuum decides to vacuum the table's TOAST table.
The autovacuum could then have a later OldestXmin than the CLUSTER does.
This means that it could see as DEAD, and remove, toast tuples belonging
to main-table tuples that the CLUSTER thinks are RECENTLY_DEAD.  Ooops.

This is only a risk because autovacuum processes a toast table
independently from its main table, and (so far as I can see)
doesn't take any lock on the main table while doing so.

We could fix the immediate problem by having CLUSTER take out a
vacuum-conflicting lock on the toast table before it determines the
OldestXmin it will use.  I wonder though if it wouldn't be smarter
to insist that autovacuum acquire some lock on the main table
when processing a toast table.  Without that, we could see this
type of problem again.  (But on the third hand, locking toast table
and then main table is no good because of deadlock risks.  And a
manual VACUUM on the toast table would be hazardous anyway.)

Thoughts?
        regards, tom lane

On Apr 30, 2011, at 8:22 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I wonder though if it wouldn't be smarter
> to insist that autovacuum acquire some lock on the main table
> when processing a toast table.

Boy, it sure seems better to avoid the above if we can. So +1 for the other way around - make CLUSTER lock the TOAST
tableif it cares about a VACUUM happening there. 

...Robert