Christopher Browne <cbbro...@gmail.com> writes:
> What seems natural-ish to me might include:
> - Stomping a bit on the FSM replacement to make sure nobody's going to
> be writing to the later extensions;
> - Watching free space during the process so the "first" extension gets
> re-opened up if the free space in the much earlier parts of the table
> (e.g. - that are not planned to be dropped off) is running out.
You seem to be thinking only about the possibility that somebody would
try to write a new tuple into the space-to-be-freed. The problem that
necessitates use of AccessExclusiveLock is that somebody could be doing
a seqscan that tries to *read* the blocks that are about to be truncated
away. We can't really improve matters much here unless we think of a
way to fix that. It would be okay if the scan just ignored blocks it
failed to read, but how do you distinguish the case from a filesystem
error that really should be reported?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
