Re: DROP TABLE and concurrent modifications

Tom Lane wrote:
> Neil Conway <neilc(at)samurai(dot)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.

Any TODO's here?

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073