Re: Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers

> Um ... why would we do this only for tables, and not for creations of
> other sorts of objects that belong to schemas?
>
>
Right, we need to do it for other objects like functions etc. too.

> Also, if we are going to believe that this is a serious problem, what
> of ALTER ... SET SCHEMA?
>
>
I admit, I hadn't thought of this.

> Also, the proposed solution is pretty silly on its face, because it has
> not removed the race condition only made the window somewhat narrower.
> You would have to acquire the lock as part of the initial schema lookup,
> not lock the OID after the fact. And could we please not do something
> as silly as translate the OID back to a string and then look up that
> string a second time?
>
>
The comment mentions that part is a kluge but that we get to re-use the
existing function because of it. The get_object_address function will bail
out anyways if the schema has vanished from down under and it does lock it
up immediately after it's found to be valid.

> (To be clear, I don't particularly believe that this is a problem worthy
> of spending code space and cycles on. But if it's deemed to be a
> problem, I want to see a solution that's actually watertight.)
>
>
Got the message.

Regards,
Nikhils