Re: [proposal] recovery_target "latest"

From: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
To: Grigory Smolkin <g(dot)smolkin(at)postgrespro(dot)ru>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: [proposal] recovery_target "latest"
Date: 2019-11-21 10:46:57
Message-ID: bbaa0a24-2103-8e93-5f9c-7edfb44b01fe@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2019-11-08 05:00, Grigory Smolkin wrote:
> Attached new patch revision, now end of available WAL is defined as the
> fact of missing required WAL.
> In case of standby, the end of WAL is defined as 2 consecutive switches
> of WAL source, that didn`t provided requested record.
> In case of streaming standby, each switch of WAL source is forced after
> 3 failed attempts to get new data from walreceiver.
>
> All constants are taken off the top of my head and serves as proof of
> concept.

Well, this is now changing the meaning of the patch quite a bit. I'm on
board with making the existing default behavior explicit. (This is
similar to how we added recovery_target_timeline = 'current' in PG12.)
Still not a fan of the name yet, but that's trivial.

If, however, you want to change the default behavior or introduce a new
behavior, as you are suggesting here, that should be a separate discussion.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro Horiguchi 2019-11-21 10:48:58 Re: [HACKERS] WAL logging problem in 9.4.3?
Previous Message Amit Kapila 2019-11-21 10:44:43 Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions