Horton

Re: [BUGS] Concurrent ALTER SEQUENCE RESTART Regression

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: Andres Freund <andres@anarazel.de>, Petr Jelinek <petr.jelinek@2ndquadrant.com>, pgsql-hackers@postgresql.org, Noah Misch <noah@leadboat.com>, Jason Petersen <jason@citusdata.com>, Michael Paquier <michael.paquier@gmail.com>, PostgreSQL mailing lists <pgsql-bugs@postgresql.org>
Date: 2017-05-11T20:35:14Z
Lists: pgsql-bugs, pgsql-hackers 
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> On 5/10/17 12:24, Andres Freund wrote:
>> Upthread I theorized whether
>> that's actually still meaningful given fastpath locking and such, but I
>> guess we'll have to evaluate that.

> [ with or without contention, fast-path locking beats the extra dance that
> open_share_lock() does. ]

That is pretty cool.  It would be good to verify the same on master,
but assuming it holds up, I think it's ok to remove open_share_lock().

			regards, tom lane

Commits

  1. Make ALTER SEQUENCE, including RESTART, fully transactional.

  2. Modify sequence catalog tuple before invoking post alter hook.

  3. Use weaker locks when updating pg_subscription_rel

  4. Add pg_sequence system catalog

  5. Modify sequence state storage to eliminate dangling-pointer problem