Horton

Re: [HACKERS] Concurrent ALTER SEQUENCE RESTART Regression

Andres Freund <andres@anarazel.de>

View thread View on postgr.es
From: Andres Freund <andres@anarazel.de>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, 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:40:12Z
Lists: pgsql-bugs, pgsql-hackers 
Hi,


On 2017-05-11 16:27:48 -0400, Peter Eisentraut wrote:
> 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.
> 
> I did some testing.

That's with the open_share_lock stuff ripped out entirely, replaced by a
plain lock acquisition within the current subxact?


> (These were within each other's variance over several runs.)
> 
> 9.2 unpatched
> Time: 64868.305 ms
> 
> 9.2 patched
> Time: 60585.317 ms
> 
> (So without contention fast-path locking beats the extra dance that
> open_share_lock() does.)

That's kind of surprising, I really wouldn't have thought it'd be faster
without.  I guess it's the overhead of sigsetjmp().  Cool.


- Andres

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