Re: BUG #13770: Extending recovery_min_apply_delay on Standby causes it to be unavailable for a while

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Greg Clough <greg(at)gclough(dot)com>
Cc: PostgreSQL mailing lists <pgsql-bugs(at)postgresql(dot)org>, Simon Riggs <simon(at)2ndQuadrant(dot)com>
Subject: Re: BUG #13770: Extending recovery_min_apply_delay on Standby causes it to be unavailable for a while
Date: 2015-12-26 13:45:57
Message-ID: CAB7nPqTYS51+ySZTUi32QVz0o1zcLDV_bO1BAtCON-7HeZwkMQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Mon, Dec 21, 2015 at 7:44 PM, Greg Clough <greg(at)gclough(dot)com> wrote:
> I didn't see any response to this, and I do believe it's an actual
> PostgreSQL bug... or at least a case of undesirable undocumented behaviour.
>
> SHORT SUMMARY: If you are using a Standby with recovery_min_apply_delay =
> 1h and you increase it to 24h, then your Standby will be unavailable for the
> next 23h.
>
> Could someone confirm my diagnosis?

When recovery_min_apply_delay is set, replay should wait for the delay
defined in the case of a COMMIT or COMMIT PREPARED record, and this
even if the minimum recovery point ensuring that standby is in a
consistent state on is not reached. In short, if there is a COMMIT
before the standby thinks that it has reached a consistent state to
allow read-only queries, which is what you are looking for, your
application won't be able to connect to the standby, and the feature
behaves correctly.

Depending on the use cases, it may be interesting to have a switch
allowing to not apply the delay should a consistent point not be
reached though...
--
Michael

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message ttmigueltt 2015-12-26 17:19:02 BUG #13833: Postgres ORDER BY value inside json causes “column does not exist” error
Previous Message Michael Paquier 2015-12-26 13:15:17 Re: BUG #13822: Slave terminated - WAL contains references to invalid page