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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
