From: | Nikhil Sontakke <nikkhils(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Nikhil Sontakke <nikhil(dot)sontakke(at)enterprisedb(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers |
Date: | 2011-11-10 16:53:46 |
Message-ID: | CANgU5ZcVJZ3mQ+6e5vOU=GsoMGL+QEVQkBrVtBTPTt6-Hk9Q5Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2011-11-10 18:06:41 | Re: warning in pg_upgrade |
Previous Message | Marko Kreen | 2011-11-10 16:24:20 | Re: Disable OpenSSL compression |