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.
