From: | Jimmy Yih <jyih(at)pivotal(dot)io> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Michael Paquier <michael(at)paquier(dot)xyz>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Prevent concurrent DROP SCHEMA when certain objects are being initially created in the namespace |
Date: | 2018-09-05 07:14:41 |
Message-ID: | CAOMx_OAwvGV7mcvJahO0PMdeR8dn8588u+ykgkJDj7ug-DuKUw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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
>
Attachment | Content-Type | Size |
---|---|---|
concurrent-schema-drop.spec | application/octet-stream | 1.1 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2018-09-05 07:23:40 | Re: Bug fix for glibc broke freebsd build in REL_11_STABLE |
Previous Message | Tom Lane | 2018-09-05 06:56:40 | Re: Implement predicate propagation for non-equivalence clauses |