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