Re: DROP TABLE and concurrent modifications

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> 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.

Yeah, good point. I don't see an easy solution, and I've got bigger
fish to fry at the moment. I'll put it down on my todo list, tho.

> 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.

ISTM we should produce a "table does not exist" error. In effect, the
ALTER TABLE RENAME is executed before the INSERT. Therefore, the state
of the db at the beginning of the execution of the INSERT reflects the
rename, so the table referred to by the INSERT no longer exists.

Blake: thanks for the bug report.

-Neil