Re: [proposal] recovery_target "latest"

Hi, this patch was waiting on author without any update/response since early December, so I've marked it as returned with feedback. Feel free to re-submit an updated version to a future CF. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support,

Re: [proposal] recovery_target "latest"

Thanks for the new version. At Sun, 8 Dec 2019 04:03:01 +0300, Grigory Smolkin wrote in > On 11/21/19 1:46 PM, Peter Eisentraut wrote: > > On 2019-11-08 05:00, Grigory Smolkin wrote: > I`ve tested it and have some thoughts/concerns: > > 1. Recovery should report the exact reason why it has bee

Re: [proposal] recovery_target "latest"

On 11/21/19 1:46 PM, Peter Eisentraut wrote: 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 provid

Re: [proposal] recovery_target "latest"

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 stan

Re: [proposal] recovery_target "latest"

At Fri, 8 Nov 2019 16:08:47 +0300, Grigory Smolkin wrote in > > On 11/8/19 7:00 AM, Grigory Smolkin wrote: > > > > On 11/7/19 4:36 PM, Grigory Smolkin wrote: > >> I gave it some thought and now think that prohibiting recovery_target > >> 'latest' and standby was a bad idea. > >> All recovery_ta

Re: [proposal] recovery_target "latest"

At Fri, 8 Nov 2019 16:08:47 +0300, Grigory Smolkin wrote in > While working on it, I stumbled upon something strange: > > why DisownLatch(&XLogCtl->recoveryWakeupLatch) is called before > ReadRecord(xlogreader, LastRec, PANIC, false) ? > Isn`t this latch may be accessed in WaitForWALToBecomeAva

Re: [proposal] recovery_target "latest"

On 11/8/19 7:00 AM, Grigory Smolkin wrote: On 11/7/19 4:36 PM, Grigory Smolkin wrote: On 11/7/19 12:56 PM, Kyotaro Horiguchi wrote: At Thu, 7 Nov 2019 12:22:28 +0300, Grigory Smolkin wrote in On 11/7/19 8:36 AM, Kyotaro Horiguchi wrote: At Thu, 7 Nov 2019 02:28:39 +0300, Grigory Smolkin

Re: [proposal] recovery_target "latest"

On 11/7/19 4:36 PM, Grigory Smolkin wrote: On 11/7/19 12:56 PM, Kyotaro Horiguchi wrote: At Thu, 7 Nov 2019 12:22:28 +0300, Grigory Smolkin wrote in On 11/7/19 8:36 AM, Kyotaro Horiguchi wrote: At Thu, 7 Nov 2019 02:28:39 +0300, Grigory Smolkin wrote in On 11/6/19 1:55 PM, Grigory Smolkin

Re: [proposal] recovery_target "latest"

On 11/7/19 12:56 PM, Kyotaro Horiguchi wrote: At Thu, 7 Nov 2019 12:22:28 +0300, Grigory Smolkin wrote in On 11/7/19 8:36 AM, Kyotaro Horiguchi wrote: At Thu, 7 Nov 2019 02:28:39 +0300, Grigory Smolkin wrote in On 11/6/19 1:55 PM, Grigory Smolkin wrote: On 11/6/19 12:56 PM, Fujii Masao w

Re: [proposal] recovery_target "latest"

At Thu, 7 Nov 2019 12:22:28 +0300, Grigory Smolkin wrote in > > On 11/7/19 8:36 AM, Kyotaro Horiguchi wrote: > > At Thu, 7 Nov 2019 02:28:39 +0300, Grigory Smolkin > > wrote in > >> On 11/6/19 1:55 PM, Grigory Smolkin wrote: > >>> On 11/6/19 12:56 PM, Fujii Masao wrote: > What happens if

Re: [proposal] recovery_target "latest"

On 11/7/19 8:36 AM, Kyotaro Horiguchi wrote: At Thu, 7 Nov 2019 02:28:39 +0300, Grigory Smolkin wrote in On 11/6/19 1:55 PM, Grigory Smolkin wrote: On 11/6/19 12:56 PM, Fujii Masao wrote: On Wed, Nov 6, 2019 at 6:33 PM Grigory Smolkin wrote: On 11/6/19 10:39 AM, Peter Eisentraut wrote:

Re: [proposal] recovery_target "latest"

At Thu, 7 Nov 2019 02:28:39 +0300, Grigory Smolkin wrote in > On 11/6/19 1:55 PM, Grigory Smolkin wrote: > > > > On 11/6/19 12:56 PM, Fujii Masao wrote: > >> On Wed, Nov 6, 2019 at 6:33 PM Grigory Smolkin > >> wrote: > >>> > >>> On 11/6/19 10:39 AM, Peter Eisentraut wrote: > This seems to

Re: [proposal] recovery_target "latest"

On 11/6/19 1:55 PM, Grigory Smolkin wrote: On 11/6/19 12:56 PM, Fujii Masao wrote: On Wed, Nov 6, 2019 at 6:33 PM Grigory Smolkin wrote: On 11/6/19 10:39 AM, Peter Eisentraut wrote: This seems to also be related to this discussion:

Re: [proposal] recovery_target "latest"

On 11/6/19 12:56 PM, Fujii Masao wrote: On Wed, Nov 6, 2019 at 6:33 PM Grigory Smolkin wrote: On 11/6/19 10:39 AM, Peter Eisentraut wrote: This seems to also be related to this discussion: Yes, in a way.

Re: [proposal] recovery_target "latest"

On Wed, Nov 6, 2019 at 6:33 PM Grigory Smolkin wrote: > > > On 11/6/19 10:39 AM, Peter Eisentraut wrote: > > This seems to also be related to this discussion: > > > > Yes, in a way. Strengthening current lax reco

Re: [proposal] recovery_target "latest"

On 11/6/19 10:39 AM, Peter Eisentraut wrote: This seems to also be related to this discussion: Yes, in a way. Strengthening current lax recovery behavior is a very good idea. I like this idea. I don't

Re: [proposal] recovery_target "latest"

This seems to also be related to this discussion: I like this idea. I don't like the name "latest". What does that mean? Other documentation talks about the "end of the archive". What does that mean? It

Re: [proposal] recovery_target "latest"

Attached new version of a patch with TAP test. On 11/5/19 11:51 AM, Grigory Smolkin wrote: Thank you for you interest in this topic! On 11/5/19 10:41 AM, Kyotaro Horiguchi wrote: Hello. At Mon, 4 Nov 2019 16:03:38 +0300, Grigory Smolkin wrote in Hello, hackers! I`d like to propose a new a

Re: [proposal] recovery_target "latest"

Thank you for you interest in this topic! On 11/5/19 10:41 AM, Kyotaro Horiguchi wrote: Hello. At Mon, 4 Nov 2019 16:03:38 +0300, Grigory Smolkin wrote in Hello, hackers! I`d like to propose a new argument for recovery_target parameter, which will stand to recovering until all available WAL

Re: [proposal] recovery_target "latest"

Hello. At Mon, 4 Nov 2019 16:03:38 +0300, Grigory Smolkin wrote in > Hello, hackers! > > I`d like to propose a new argument for recovery_target parameter, > which will stand to recovering until all available WAL segments are > applied. > > Current PostgreSQL recovery default behavior(when no