Re: DROP TABLE and concurrent modifications

Neil Conway <neilc@samurai.com> writes:
> Assuming my analysis is correct, is this a bug?

Yes, though a low-priority one in my mind.  There is a TODO item about
it:

* Acquire lock on a relation before building a relcache entry for it

(The TODO item is a bit unspecific though, since the issue here probably
has to do with reusing an existing relcache entry rather than starting
from scratch.)

The difficulty with acquiring lock earlier is that to acquire lock,
you need to know the relation's shared/unshared status as well as its
OID.  We'd need to do something with all the code that assumes that
an OID is sufficient information for opening relations.

For the case of DROP TABLE, we don't really need to solve this problem;
it would be sufficient to make the error message a bit more friendly
(we could possibly save aside the relation name before trying to rebuild
the cache entry).  I think the real reason for the TODO was concerns
about ALTER TABLE RENAME --- if someone else is doing that, you could
end up accessing a table that, by the time you've locked it, has a
different name than you were looking up.  It's not entirely clear to me
what *should* happen in that case, but silently continuing is arguably
not the best idea.
        regards, tom lane