On Fri, Mar 25, 2011 at 5:56 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > 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?
It's struck me a number of times that it would make some things simpler if we were able to maintain some state in shared memory about the tables people were using - for example, in this case, we could cache the table size, or the fact that vacuum has just truncated away N blocks, or, uh, something. *waves hands* But it's hard to know how such an area could reasonably be sized or managed. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
