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

Andres Freund <andres(at)anarazel(dot)de> writes:
> On September 4, 2018 9:11:25 PM PDT, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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