Re: [BUGS] Concurrent ALTER SEQUENCE RESTART Regression

On 03/05/17 07:22, Andres Freund wrote:
> On 2017-05-03 07:19:16 +0200, Petr Jelinek wrote:
>> On 02/05/17 20:40, Robert Haas wrote:
>>> On Tue, May 2, 2017 at 1:36 PM, Andres Freund <andres@anarazel.de> wrote:
>>>>> But by the same token surely we don't want to do
>>>>> CatalogUpdateIndexes() while holding the buffer lock either; mutual
>>>>> exclusion needs to be managed at some higher level, using, say, a
>>>>> heavyweight tuple lock.
>>>>
>>>> Right, I don't want that to happen - I think it means we need a proper
>>>> lock here, but Peter seems to be against that for reasons I don't
>>>> understand.  It's what Michael had suggested in:
>>>> http://archives.postgresql.org/message-id/CAB7nPqRev_wK4k39hQBpQZRQ17v29guxfobnnmTYT_-hUU67BA%40mail.gmail.com
>>>
>>> Yes, I didn't understand Peter's objection, either.  It's true that
>>> there are multiple levels of locks here, but if we've got things
>>> failing that used to work, then we've not got all the right ones.
>>>
>>
>> I do understand the objection, Peter wants to keep metadata
>> transactional which I would prefer as well (and that's not going to be
>> the case with Michael's approach).
> 
> Huh? How does increasing the locklevel (from AccessShare to
> ShareUpdateExclusive) make it nontransactional?
> 

Ah damn, I looked at wrong patch (the one that did inline heap update,
Michael produces too many patches ;)).

Yes that one is good.

>> 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?

--  Petr Jelinek                  http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training &
Services


-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs