Re: Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers
Date
Msg-id 8230.1320939035@sss.pgh.pa.us
Whole thread Raw
In response to Re: Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers  (Nikhil Sontakke <nikkhils@gmail.com>)
Responses Re: Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers
List pgsql-hackers
Nikhil Sontakke <nikkhils@gmail.com> writes:
> PFA, a patch against git head. We take the AccessShareLock lock on the
> schema in DefineRelation now.

Um ... why would we do this only for tables, and not for creations of
other sorts of objects that belong to schemas?

Also, if we are going to believe that this is a serious problem, what
of ALTER ... SET SCHEMA?

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?

(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.)
        regards, tom lane


pgsql-hackers by date:

Previous
From: Rudyar
Date:
Subject: MPI programming in postgreSQL backend source code
Next
From: Tom Lane
Date:
Subject: Re: Re: [patch] Include detailed information about a row failing a CHECK constraint into the error message