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
