On Sat, Jan 21, 2012 at 10:11 AM, Simon Riggs <si...@2ndquadrant.com> wrote: > Your caution is wise. All users of an index have already checked > whether the index is usable at plan time, so although there is much > code that assumes they can look at the index itself, that is not > executed until after the correct checks. > > I'll look at VACUUM and other utilities, so thanks for that. > > I don't see much point in having the higher level lock, except perhaps > as a test this code works.
I thought of another way this can cause a problem: suppose that while we're dropping the relation with only ShareUpdateExclusiveLock, we get as far as calling DropRelFileNodeBuffers. Just after we finish, some other process that holds AccessShareLock or RowShareLock or RowExclusiveLock reads and perhaps even dirties a page in the relation. Now we've got pages in the buffer pool that might even be dirty, but the backing file is truncated or perhaps removed altogether. If the page is dirty, I think the background writer will eventually choke trying to write out the page. If the page is not dirty, I'm less certain whether anything is going to explode violently, but it seems mighty sketchy to have pages in the buffer pool with a buffer tag that don't exist any more. As the comment says: * It is the responsibility of higher-level code to ensure that the * deletion or truncation does not lose any data that could be needed * later. It is also the responsibility of higher-level code to ensure * that no other process could be trying to load more pages of the * relation into buffers. ...and of course, the intended mechanism is an AccessExclusiveLock. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
