Re: Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers
Дата
Msg-id 8230.1320939035@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers  (Nikhil Sontakke <nikkhils@gmail.com>)
Ответы Re: Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers  (Nikhil Sontakke <nikkhils@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Rudyar
Дата:
Сообщение: MPI programming in postgreSQL backend source code
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Re: [patch] Include detailed information about a row failing a CHECK constraint into the error message