Tom Lane wrote: > What I propose we do about this is put the same check into TRUNCATE, > CLUSTER, and REINDEX that is already in ALTER TABLE, namely that we > reject the command if the current transaction is already holding > the table open.
+1. > The issue Steven directly complained of is a potential for undetected > deadlock via LockBufferForCleanup. Ordinarily, buffer-level locks don't > pose a deadlock risk because we don't hold one while trying to acquire > another (except in UPDATE, which uses an ordering rule to avoid the > risk). The problem with LockBufferForCleanup is that it can be blocked > by a mere pin, which another backend could well hold while trying to > acquire a lock that will be blocked by VACUUM. Seems like a hard problem. I wonder if we can invoke the deadlock checker in LockBufferForCleanup. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend