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
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 |