There was just another complaint about something we've heard about before, namely that dropping a child table doesn't interact nicely with queries concurrently accessing the parent table: http://archives.postgresql.org/pgsql-bugs/2009-05/msg00113.php
As I responded there, this isn't fixable by the obvious method of making DROP TABLE try to lock the parent too. On reflection though it seems that there is a reasonably simple solution: we could make find_inheritance_children() and find_all_inheritors() acquire lock on each child table as they scan pg_inherits, and do try_relation_open() or equivalent to see if the child still exists. If not, assume the table just got dropped and ignore the pg_inherits entry. This would require an API change to let the callers tell them what type of lock they intend to acquire on each table, but overall it shouldn't result in any visible change in query behavior in normal cases --- we're just acquiring relation locks a bit earlier than we did before. The only arguable downside I can see is that if pg_inherits happens to contain a corrupt row with a bad child OID, you'd never hear about it. But that doesn't seem like a big problem. Since 8.4 already contains a number of changes designed to make concurrent-DROP scenarios work more safely than before, I'm strongly tempted to sneak this change into 8.4. 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