Re: Prevent concurrent DROP SCHEMA when certain objects are beinginitially created in the namespace

Поиск
Список
Период
Сортировка
От Jimmy Yih
Тема Re: Prevent concurrent DROP SCHEMA when certain objects are beinginitially created in the namespace
Дата
Msg-id CAOMx_OAwvGV7mcvJahO0PMdeR8dn8588u+ykgkJDj7ug-DuKUw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Prevent concurrent DROP SCHEMA when certain objects are being initially created in the namespace  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Prevent concurrent DROP SCHEMA when certain objects are beinginitially created in the namespace  (Michael Paquier <michael@paquier.xyz>)
Список pgsql-hackers
Something which would be good to have for all those queries is a set of
isolation tests.  No need for multiple specs, you could just use one
spec with one session defining all the object types you would like to
work on.  How did you find this object list?  Did you test all the
objects available manually?
Attached the isolation spec file.  I originally was only going to fix the simple CREATE TYPE scenario but decided to look up other objects that can reside in namespaces and ended up finding a handful of others.  I tested each one manually before and after adding the AccessShareLock acquire on the schema.

I think that line of thought leads to an enormous increase in locking
overhead, for which we'd get little if any gain in usability.  So my
inclination is to make an engineering judgment that we won't fix this.
As I was creating this patch, I had similar feelings on the locking overhead and was curious how others would feel about it as well.

Regards,
Jimmy


On Tue, Sep 4, 2018 at 10:05 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Andres Freund <andres@anarazel.de> writes:
> On September 4, 2018 9:11:25 PM PDT, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I think that line of thought leads to an enormous increase in locking
>> overhead, for which we'd get little if any gain in usability.  So my
>> inclination is to make an engineering judgment that we won't fix this.

> Haven't we already significantly started down this road, to avoid a lot of the "tuple concurrently updated" type errors?

Not that I'm aware of.  We do not take locks on schemas, nor functions,
nor any other of the object types I mentioned.

> Would expanding this a git further really be that noticeable?

Frankly, I think it would be not so much "noticeable" as "disastrous".

Making the overhead tolerable would require very large compromises
in coverage, perhaps like "we'll only lock during DDL not DML".
At which point I'd question why bother.  We've seen no field reports
(that I can recall offhand, anyway) that trace to not locking these
objects.

                        regards, tom lane

Вложения

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Implement predicate propagation for non-equivalence clauses
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: Bug fix for glibc broke freebsd build in REL_11_STABLE