On Wed, Sep 5, 2018 at 1:05 AM, Tom Lane wrote:
>> 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
On Sat, Sep 08, 2018 at 04:21:34PM -0400, Tom Lane wrote:
> I'm still not very happy about this, mainly because it seems like
> (a) it's papering over just a small fraction of the true problem
Check.
> (b) there's been no discussion about cost-benefit tradeoffs.
Noted. I am not sure how to
Michael Paquier writes:
> This way if any refactoring is done with this routine, then we don't
> break schema lock logic. Andres, Tom and others, any objections?
I'm still not very happy about this, mainly because it seems like
(a) it's papering over just a small fraction of the true problem
On Thu, Sep 06, 2018 at 05:19:15PM -0300, FabrÃzio de Royes Mello wrote:
> I also run some similar tests as Jimmy pointed and using PLpgSQL to execute
> DDLs and the new consistent behavior is ok. Also I run one session using
> DROP SCHEMA at end and after COMMIT the session 2 report 'ERROR:
On Thu, Sep 6, 2018 at 4:22 PM Michael Paquier wrote:
>
> On Wed, Sep 05, 2018 at 09:23:37AM -0700, Andres Freund wrote:
> > Well, we kinda do, during some of their own DDL. CF
> > AcquireDeletionLock(), RangeVarGetAndCheckCreationNamespace(), and other
> > LockDatabaseObject() callers. The
> >
On Wed, Sep 05, 2018 at 09:23:37AM -0700, Andres Freund wrote:
> Well, we kinda do, during some of their own DDL. CF
> AcquireDeletionLock(), RangeVarGetAndCheckCreationNamespace(), and other
> LockDatabaseObject() callers. The
> RangeVarGetAndCheckCreationNamespace() even locks the schema an
On Wed, Sep 05, 2018 at 12:14:41AM -0700, Jimmy Yih wrote:
> 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
Hi,
On 2018-09-05 01:05:54 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On September 4, 2018 9:11:25 PM PDT, Tom Lane 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
> >>
>
> 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
Andres Freund writes:
> On September 4, 2018 9:11:25 PM PDT, Tom Lane 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.
On September 4, 2018 9:11:25 PM PDT, Tom Lane wrote:
>Michael Paquier writes:
>> On Tue, Sep 04, 2018 at 03:09:21PM -0700, Jimmy Yih wrote:
>>> When an empty namespace is being initially populated with certain
>objects,
>>> it is possible for a DROP SCHEMA operation to come in and delete the
Michael Paquier writes:
> On Tue, Sep 04, 2018 at 03:09:21PM -0700, Jimmy Yih wrote:
>> When an empty namespace is being initially populated with certain objects,
>> it is possible for a DROP SCHEMA operation to come in and delete the
>> namespace without using CASCADE.
> It seems to me that we
On Tue, Sep 04, 2018 at 03:09:21PM -0700, Jimmy Yih wrote:
> When an empty namespace is being initially populated with certain objects,
> it is possible for a DROP SCHEMA operation to come in and delete the
> namespace without using CASCADE. These objects would be created but are
> left unusable.
Hello,
When an empty namespace is being initially populated with certain objects,
it is possible for a DROP SCHEMA operation to come in and delete the
namespace without using CASCADE. These objects would be created but are
left unusable. This is capable of leaving behind pg_class, pg_type, and
14 matches
Mail list logo