Thread

Commits

  1. Restore behavior for replication origin drop

  2. Add a WAIT option to DROP_REPLICATION_SLOT

  3. Fix race conditions in replication slot operations

  1. [PATCH] Fix drop replication slot blocking instead of returning error

    Simone Gotti <simone.gotti@gmail.com> — 2017-08-24T13:38:20Z

    Hi all,
    
    I noticed that in postgres 10beta3, calling pg_drop_replication_slot on an
    active slot will block until it's released instead of returning an error
    like
    done in pg 9.6. Since this is a change in the previous behavior and the docs
    wasn't changed I made a patch to restore the previous behavior.
    
    Thanks,
    
    Simone.
    
    --
    
    after git commit 9915de6c1cb calls to pg_drop_replication_slot or the
    replication protocol DROP_REPLICATION_SLOT command will block when a
    slot is in use instead of returning an error as before (as the doc
    states).
    
    This patch will set nowait to true to restore the previous
    behavior.
    
  2. Re: [PATCH] Fix drop replication slot blocking instead of returning error

    Noah Misch <noah@leadboat.com> — 2017-08-26T08:07:28Z

    On Thu, Aug 24, 2017 at 03:38:20PM +0200, Simone Gotti wrote:
    > I noticed that in postgres 10beta3, calling pg_drop_replication_slot on an
    > active slot will block until it's released instead of returning an error
    > like
    > done in pg 9.6. Since this is a change in the previous behavior and the docs
    > wasn't changed I made a patch to restore the previous behavior.
    > 
    > Thanks,
    > 
    > Simone.
    > 
    > --
    > 
    > after git commit 9915de6c1cb calls to pg_drop_replication_slot or the
    > replication protocol DROP_REPLICATION_SLOT command will block when a
    > slot is in use instead of returning an error as before (as the doc
    > states).
    > 
    > This patch will set nowait to true to restore the previous
    > behavior.
    
    [Action required within three days.  This is a generic notification.]
    
    The above-described topic is currently a PostgreSQL 10 open item.  Álvaro,
    since you committed the patch believed to have created it, you own this open
    item.  If some other commit is more relevant or if this does not belong as a
    v10 open item, please let us know.  Otherwise, please observe the policy on
    open item ownership[1] and send a status update within three calendar days of
    this message.  Include a date for your subsequent status update.  Testers may
    discover new open items at any time, and I want to plan to get them all fixed
    well in advance of shipping v10.  Consequently, I will appreciate your efforts
    toward speedy resolution.  Thanks.
    
    [1] https://www.postgresql.org/message-id/20170404140717.GA2675809%40tornado.leadboat.com
    
    
    
  3. Re: Re: [PATCH] Fix drop replication slot blocking instead of returning error

    Alvaro Herrera <alvherre@2ndquadrant.com> — 2017-08-29T10:04:33Z

    Noah Misch wrote:
    > On Thu, Aug 24, 2017 at 03:38:20PM +0200, Simone Gotti wrote:
    > > I noticed that in postgres 10beta3, calling pg_drop_replication_slot on an
    > > active slot will block until it's released instead of returning an error
    > > like
    > > done in pg 9.6. Since this is a change in the previous behavior and the docs
    > > wasn't changed I made a patch to restore the previous behavior.
    
    > > after git commit 9915de6c1cb calls to pg_drop_replication_slot or the
    > > replication protocol DROP_REPLICATION_SLOT command will block when a
    > > slot is in use instead of returning an error as before (as the doc
    > > states).
    > > 
    > > This patch will set nowait to true to restore the previous
    > > behavior.
    
    > The above-described topic is currently a PostgreSQL 10 open item.
    
    Looking at it now -- next report tomorrow.
    
    
    -- 
    Álvaro Herrera                https://www.2ndQuadrant.com/
    PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
    
    
    
  4. Re: [PATCH] Fix drop replication slot blocking instead of returning error

    Alvaro Herrera <alvherre@2ndquadrant.com> — 2017-08-29T10:13:02Z

    Simone Gotti wrote:
    > Hi all,
    > 
    > I noticed that in postgres 10beta3, calling pg_drop_replication_slot on an
    > active slot will block until it's released instead of returning an error
    > like
    > done in pg 9.6. Since this is a change in the previous behavior and the docs
    > wasn't changed I made a patch to restore the previous behavior.
    
    Changing that behavior was the entire point of the cited commit.
    
    A better fix, from my perspective, is to amend the docs as per the
    attached patch.  This is what would be useful for logical replication,
    which is what replication slots were invented for in the first place.
    If you disagree, let's discuss what other use cases you have, and we can
    come up with alternatives that satisfy both.  I think a decent answer,
    but one which would create a bit of extra churn, would be to have an
    optional boolean flag in the command/function for "nowait", instead of
    hardcoding either behavior.
    
    -- 
    Álvaro Herrera                https://www.2ndQuadrant.com/
    PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
    
  5. Re: [PATCH] Fix drop replication slot blocking instead of returning error

    Simone Gotti <simone.gotti@gmail.com> — 2017-08-29T11:42:05Z

    On Tue, Aug 29, 2017 at 12:13 PM, Alvaro Herrera
    <alvherre@2ndquadrant.com> wrote:
    >
    
    Hi Alvaro,
    
    > Simone Gotti wrote:
    > > Hi all,
    > >
    > > I noticed that in postgres 10beta3, calling pg_drop_replication_slot on an
    > > active slot will block until it's released instead of returning an error
    > > like
    > > done in pg 9.6. Since this is a change in the previous behavior and the docs
    > > wasn't changed I made a patch to restore the previous behavior.
    >
    > Changing that behavior was the entire point of the cited commit.
    
    Sorry, I was thinking that the new behavior was needed for internal
    future functions since the doc wasn't changed.
    
    >
    > A better fix, from my perspective, is to amend the docs as per the
    > attached patch.  This is what would be useful for logical replication,
    > which is what replication slots were invented for in the first place.
    
    I don't know the reasons why the new behavior is better for logical
    replication so I trust you. We are using repl slots for physical
    replication.
    
    > If you disagree, let's discuss what other use cases you have, and we can
    > come up with alternatives that satisfy both.
    
    I just faced the opposite problem, in stolon [1], we currently rely on
    the previous behavior. i.e. we don't want to block waiting for a slot
    to be released (that under some partitioning conditions could not
    happen for a long time), but prefer to continue retrying the drop
    later. Now we partially avoid blocking timing out the drop operation
    after some seconds.
    Another idea will be to query the slot status before doing the drop
    but will lead to a race condition (probably the opposite that that
    commit was fixing) if the slot is acquired between the query and the
    drop.
    
    > I think a decent answer,
    > but one which would create a bit of extra churn, would be to have an
    > optional boolean flag in the command/function for "nowait", instead of
    > hardcoding either behavior.
    
    I think that this will be the best fix. I'm not sure on the policy of
    these commands and if backward compatibility will be better (in such
    case the old behavior should be the default and a new "wait" flag
    could be added).
    
    If the default behavior is going to change we have to add different
    code for postgres >= 10.
    
    
    Thanks,
    Simone.
    
    
    [1] https://github.com/sorintlab/stolon
    
    >
    >
    > --
    > Álvaro Herrera                https://www.2ndQuadrant.com/
    > PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
    
    
    
  6. Re: [PATCH] Fix drop replication slot blocking instead of returning error

    Andres Freund <andres@anarazel.de> — 2017-08-29T14:02:59Z

    Hi,
    
    On 2017-08-29 13:42:05 +0200, Simone Gotti wrote:
    > On Tue, Aug 29, 2017 at 12:13 PM, Alvaro Herrera
    > <alvherre@2ndquadrant.com> wrote:
    > >
    > 
    > Hi Alvaro,
    > 
    > > Simone Gotti wrote:
    > > > Hi all,
    > > >
    > > > I noticed that in postgres 10beta3, calling pg_drop_replication_slot on an
    > > > active slot will block until it's released instead of returning an error
    > > > like
    > > > done in pg 9.6. Since this is a change in the previous behavior and the docs
    > > > wasn't changed I made a patch to restore the previous behavior.
    > >
    > > Changing that behavior was the entire point of the cited commit.
    > 
    > Sorry, I was thinking that the new behavior was needed for internal
    > future functions since the doc wasn't changed.
    
    FWIW, I also don't think it's ok to just change the behaviour
    unconditionally and without a replacement for existing behaviour.
    
    
    Greetings,
    
    Andres Freund
    
    
    
  7. Re: [PATCH] Fix drop replication slot blocking instead of returning error

    Craig Ringer <craig@2ndquadrant.com> — 2017-08-30T00:36:00Z

    On 29 August 2017 at 22:02, Andres Freund <andres@anarazel.de> wrote:
    
    > Hi,
    >
    > On 2017-08-29 13:42:05 +0200, Simone Gotti wrote:
    > > On Tue, Aug 29, 2017 at 12:13 PM, Alvaro Herrera
    > > <alvherre@2ndquadrant.com> wrote:
    > > >
    > >
    > > Hi Alvaro,
    > >
    > > > Simone Gotti wrote:
    > > > > Hi all,
    > > > >
    > > > > I noticed that in postgres 10beta3, calling pg_drop_replication_slot
    > on an
    > > > > active slot will block until it's released instead of returning an
    > error
    > > > > like
    > > > > done in pg 9.6. Since this is a change in the previous behavior and
    > the docs
    > > > > wasn't changed I made a patch to restore the previous behavior.
    > > >
    > > > Changing that behavior was the entire point of the cited commit.
    > >
    > > Sorry, I was thinking that the new behavior was needed for internal
    > > future functions since the doc wasn't changed.
    >
    > FWIW, I also don't think it's ok to just change the behaviour
    > unconditionally and without a replacement for existing behaviour.
    
    
    Seems like it just needs a new argument nowait DEFAULT false
    
    
     Craig Ringer                   http://www.2ndQuadrant.com/
     PostgreSQL Development, 24x7 Support, Training & Services
    
  8. Re: [PATCH] Fix drop replication slot blocking instead of returning error

    Alvaro Herrera <alvherre@2ndquadrant.com> — 2017-08-30T13:33:13Z

    Craig Ringer wrote:
    
    > > FWIW, I also don't think it's ok to just change the behaviour
    > > unconditionally and without a replacement for existing behaviour.
    > 
    > Seems like it just needs a new argument nowait DEFAULT false
    
    I added a WAIT flag to DROP_REPLICATION_SLOT, preliminary patch
    attached.  Running tests now.
    
    -- 
    Álvaro Herrera                https://www.2ndQuadrant.com/
    PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
    
  9. Re: [PATCH] Fix drop replication slot blocking instead of returning error

    Alvaro Herrera <alvherre@2ndquadrant.com> — 2017-08-30T13:39:22Z

    And another patch to restore behavior to replication origin drop.
    
    -- 
    Álvaro Herrera                https://www.2ndQuadrant.com/
    PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
    
  10. Re: Re: [PATCH] Fix drop replication slot blocking instead of returning error

    Noah Misch <noah@leadboat.com> — 2017-09-01T02:14:03Z

    On Tue, Aug 29, 2017 at 12:04:33PM +0200, Alvaro Herrera wrote:
    > Noah Misch wrote:
    > > On Thu, Aug 24, 2017 at 03:38:20PM +0200, Simone Gotti wrote:
    > > > I noticed that in postgres 10beta3, calling pg_drop_replication_slot on an
    > > > active slot will block until it's released instead of returning an error
    > > > like
    > > > done in pg 9.6. Since this is a change in the previous behavior and the docs
    > > > wasn't changed I made a patch to restore the previous behavior.
    > 
    > > > after git commit 9915de6c1cb calls to pg_drop_replication_slot or the
    > > > replication protocol DROP_REPLICATION_SLOT command will block when a
    > > > slot is in use instead of returning an error as before (as the doc
    > > > states).
    > > > 
    > > > This patch will set nowait to true to restore the previous
    > > > behavior.
    > 
    > > The above-described topic is currently a PostgreSQL 10 open item.
    > 
    > Looking at it now -- next report tomorrow.
    
    This PostgreSQL 10 open item is past due for your status update.  Kindly send
    a status update within 24 hours, and include a date for your subsequent status
    update.  Refer to the policy on open item ownership:
    https://www.postgresql.org/message-id/20170404140717.GA2675809%40tornado.leadboat.com
    
    
    
  11. Re: [PATCH] Fix drop replication slot blocking instead of returning error

    Alvaro Herrera <alvherre@alvh.no-ip.org> — 2017-09-01T14:31:17Z

    Both patches pushed, which should close the open item.
    
    -- 
    Álvaro Herrera                https://www.2ndQuadrant.com/
    PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
    
    
    
  12. Re: [PATCH] Fix drop replication slot blocking instead of returning error

    Simone Gotti <simone.gotti@gmail.com> — 2017-09-01T14:36:23Z

    On Fri, Sep 1, 2017 at 4:31 PM, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
    >
    > Both patches pushed, which should close the open item.
    
    Hi Alvaro,
    
    thanks a lot!
    
    Cheers,
    Simone.
    
    
    >
    > --
    > Álvaro Herrera                https://www.2ndQuadrant.com/
    > PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services