Re: Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers

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

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Αναστάσιος Αρβανίτης
Дата:
Сообщение: Parsing output of EXPLAIN command in PostgreSQL
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: warning in pg_upgrade