Horton

Re: [HACKERS] 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: Andres Freund <andres@anarazel.de>
Cc: Petr Jelinek <petr.jelinek@2ndquadrant.com>, Peter Eisentraut <peter.eisentraut@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-10T17:28:39Z
Lists: pgsql-bugs, pgsql-hackers 
Andres Freund <andres@anarazel.de> writes:
> On 2017-05-10 10:29:02 -0400, Tom Lane wrote:
>> As long as it doesn't block, the change in lock strength doesn't actually
>> make any speed difference does it?

> The issue isn't the strength, but that we currently have this weird
> hackery around open_share_lock():

Oh!  I'd forgotten about that.  Yes, if we change that then we'd
need to do some performance checking.

			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