On Wed, May 3, 2017 at 2:26 PM, Petr Jelinek
<petr.jelinek@2ndquadrant.com> wrote:
>>> It could be done if ALTER SEQUENCE held stronger lock on the sequence
>>> relation though, but it needs to block nextval as well in that case
>>> (which I think would mean nextval would need row share lock, unless we
>>> are okay with doing access exclusive lock during ALTER) as I mentioned
>>> up thread.
>>
>> That one is more complicated, because AccessShareLocks on sequences are
>> held on for performance reasons... Possibly not really required
>> anymore, due to fast-path locks? Still'd increase the number of
>> lock/unlock cycles.
>
> Right but won't we still have problem with nextval ignoring the ALTER
> until it commits without that?
Right, the only thing that you can really do here is to take a
stronger lock on the parent object, and that will be disruptive for
concurrent sessions. Not sure what Peter wants to do here, but
3d092fe5 is just putting sugar powder on top of a cake badly-cooked.
What we ought to do instead is review the recipy as users should never
be able to face "tuple concurrently updated". So as far as I can see,
this open item is not addressed. And the issues with locking around
XLOG/catalog updates are not solved either.
--
Michael
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
