From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org, Noah Misch <noah(at)leadboat(dot)com>, Jason Petersen <jason(at)citusdata(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] Concurrent ALTER SEQUENCE RESTART Regression |
Date: | 2017-05-12 03:59:56 |
Message-ID: | 25950.1494561596@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2017-05-11 17:21:18 -0400, Tom Lane wrote:
>> I doubt my machine is 6X faster than yours,
>> so this indicates that the subtransaction overhead is pretty real.
> Isn't that pretty much the point? The whole open_share_lock()
> optimization looks like it really only can make a difference with
> subtransactions?
Uh, no; I'm pretty sure that that code is older than subtransactions.
The point of it is to avoid taking and releasing a lock over and over
within a single transaction.
>> Hm. I don't think that's a sufficient code change, because if you do it
>> like that then the lock remains held after nextval() returns.
> Hm? That's not new, is it? We previously did a LockRelationOid(seq->relid) and
> then relation_open(seq->relid, NoLock)?
Right, but the existing code is *designed* to hold the lock till end of
top-level transaction, regardless of what happens in any subtransaction.
My understanding of your complaint is that you do not think that's OK
for any lock stronger than AccessShareLock.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | sebastian.calbaza | 2017-05-12 13:00:33 | BUG #14648: counts for queries using array unnesting is incorrect |
Previous Message | Tom Lane | 2017-05-11 22:32:43 | Re: BUG #14646: performance hint to remove |
From | Date | Subject | |
---|---|---|---|
Next Message | Bossart, Nathan | 2017-05-12 04:06:51 | Re: [Proposal] Allow users to specify multiple tables in VACUUM commands |
Previous Message | Amit Kapila | 2017-05-12 03:57:30 | Re: UPDATE of partition key |