At Wed, 29 Jan 2020 16:01:46 +0100, Peter Eisentraut
wrote in
> On 2020-01-28 06:01, Kyotaro Horiguchi wrote:
> > The code looks fine, renaming reachedStopPoint to
> > reachedRecoveryTarget looks very nice. Doc part looks fine, too.
> > PostgresNode.pm
> > +Is has_restoring is used, standby mode
On 2020-01-28 06:01, Kyotaro Horiguchi wrote:
Hello.
At Mon, 27 Jan 2020 12:16:02 +0100, Peter Eisentraut
wrote in
On 2020-01-15 05:02, Kyotaro Horiguchi wrote:
FWIW, I restate this (perhaps) more clearly.
At Wed, 15 Jan 2020 11:02:24 +0900 (JST), Kyotaro Horiguchi
wrote in
recvoery_target
Great job with the patch Peter, it has been even cleaner than before after you
moved the check.
> "Peter Eisentraut" skrev 27. januar 2020
> kl. 12:16:
Hello.
At Mon, 27 Jan 2020 12:16:02 +0100, Peter Eisentraut
wrote in
> On 2020-01-15 05:02, Kyotaro Horiguchi wrote:
> > FWIW, I restate this (perhaps) more clearly.
> > At Wed, 15 Jan 2020 11:02:24 +0900 (JST), Kyotaro Horiguchi
> > wrote in
> >> recvoery_target_* is not cleared after startup
On 2020-01-15 05:02, Kyotaro Horiguchi wrote:
FWIW, I restate this (perhaps) more clearly.
At Wed, 15 Jan 2020 11:02:24 +0900 (JST), Kyotaro Horiguchi
wrote in
recvoery_target_* is not cleared after startup. If a server crashed
just after the last shutdown checkpoint, any recovery_target_* se
> "Peter Eisentraut" skrev 14. januar 2020
> kl. 21:13:
>
> On 2019-12-11 12:40, Leif Gunnar Erlandsen wrote:
>> Adding patch written for 13dev from git
>> "Michael Paquier" skrev 1. desember 2019 kl. 03:08:
>> On Fri, Nov 22, 2019 at 11:26:59AM +, Leif Gunnar Erlandsen wrote:
>
>> No it d
FWIW, I restate this (perhaps) more clearly.
At Wed, 15 Jan 2020 11:02:24 +0900 (JST), Kyotaro Horiguchi
wrote in
> recvoery_target_* is not cleared after startup. If a server crashed
> just after the last shutdown checkpoint, any recovery_target_* setting
> prevents the server from starting re
At Tue, 14 Jan 2020 21:13:51 +0100, Peter Eisentraut
wrote in
> On 2019-12-11 12:40, Leif Gunnar Erlandsen wrote:
> > Adding patch written for 13dev from git
> > "Michael Paquier" skrev 1. desember 2019
> > kl. 03:08:
> >
> >> On Fri, Nov 22, 2019 at 11:26:59AM +, Leif Gunnar Erlandsen wro
On 2019-12-11 12:40, Leif Gunnar Erlandsen wrote:
Adding patch written for 13dev from git
"Michael Paquier" skrev 1. desember 2019 kl. 03:08:
On Fri, Nov 22, 2019 at 11:26:59AM +, Leif Gunnar Erlandsen wrote:
No it does not. It works well to demonstrate its purpose though.
And it might
Adding patch written for 13dev from git
"Michael Paquier" skrev 1. desember 2019 kl. 03:08:
> On Fri, Nov 22, 2019 at 11:26:59AM +, Leif Gunnar Erlandsen wrote:
>
>> No it does not. It works well to demonstrate its purpose though.
>> And it might be to stop with FATAL would be more correct.
On Fri, Nov 22, 2019 at 11:26:59AM +, Leif Gunnar Erlandsen wrote:
> No it does not. It works well to demonstrate its purpose though.
> And it might be to stop with FATAL would be more correct.
This is still under active discussion. Please note that the latest
patch does not apply, so a rebas
"Peter Eisentraut" skrev 22. november 2019
kl. 11:50:
> On 2019-11-21 13:50, Leif Gunnar Erlandsen wrote:
>
>> Pausing was choosen in the patch as pause was the expected behaivior if
>> target was reached.
>
> Pausing is the expect behavior when the target is reached because that is the
> de
"Kyotaro Horiguchi" skrev 22. november 2019 kl. 05:26:
> Hello, Lief, Peter.
>
> At Thu, 21 Nov 2019 12:50:18 +, "Leif Gunnar Erlandsen"
> wrote in
>
>> Adding another patch which is not only for recovery_target_time but also for
>> xid, name and lsn.
>>
>> After studying this a bit mo
On 2019-11-21 13:50, Leif Gunnar Erlandsen wrote:
Pausing was choosen in the patch as pause was the expected behaivior if target
was reached.
Pausing is the expect behavior when the target is reached because that
is the default setting of recovery_target_action. Your patch does not
take rec
Hello, Lief, Peter.
At Thu, 21 Nov 2019 12:50:18 +, "Leif Gunnar Erlandsen"
wrote in
> Adding another patch which is not only for recovery_target_time but also for
> xid, name and lsn.
>
> > After studying this a bit more, I think the current behavior is totally
> > bogus and needs a ser
Adding another patch which is not only for recovery_target_time but also for
xid, name and lsn.
> After studying this a bit more, I think the current behavior is totally bogus
> and needs a serious
> rethink.
>
> If you specify a recovery target and it is reached, recovery pauses
> (depending
After studying this a bit more, I think the current behavior is totally
bogus and needs a serious rethink.
If you specify a recovery target and it is reached, recovery pauses
(depending on recovery_target_action).
If you specify a recovery target and it is not reached when the end of
the arc
>"Peter Eisentraut" skrev 6. november 2019
>kl. 08:32:
>
>> Btw., this discussion/patch seems related:
>> https://www.postgresql.org/message-id/flat/a3f650f1-fb0f-c913-a000-a4671f12a...@postgrespro.ru
I have read through this other proposal. As far as I could see in the suggested
patch, it does
On 2019-09-17 13:23, Leif Gunnar Erlandsen wrote:
This patch allows PostgreSQL to pause recovery before PITR target is reached
if recovery_target_time is specified.
Btw., this discussion/patch seems related:
https://www.postgresql.org/message-id/flat/a3f650f1-fb0f-c913-a000-a4671f12a013%40post
On Fri, Nov 1, 2019 at 9:41 PM Peter Eisentraut
wrote:
>
> On 2019-10-21 08:44, Fujii Masao wrote:
> > Probably we can use standby mode + recovery target setting for
> > the almost same purpose. In this configuration, if end-of-WAL is reached
> > before recovery target, the startup process keeps w
On 2019-10-21 08:44, Fujii Masao wrote:
Probably we can use standby mode + recovery target setting for
the almost same purpose. In this configuration, if end-of-WAL is reached
before recovery target, the startup process keeps waiting for new WAL to
be available. Then, if recovery target is reache
On Sun, Oct 20, 2019 at 4:46 AM Peter Eisentraut
wrote:
>
> On 2019-09-17 13:23, Leif Gunnar Erlandsen wrote:
> > This patch allows PostgreSQL to pause recovery before PITR target is reached
> > if recovery_target_time is specified.
> >
> > Missing WAL's could then be restored from backup and appl
On Sat, 2019-10-19 at 21:45 +0200, Peter Eisentraut wrote:
> On 2019-09-17 13:23, Leif Gunnar Erlandsen wrote:
> > This patch allows PostgreSQL to pause recovery before PITR target is
> > reached
> > if recovery_target_time is specified.
> >
> > Missing WAL's could then be restored from backup a
On 2019-09-17 13:23, Leif Gunnar Erlandsen wrote:
> This patch allows PostgreSQL to pause recovery before PITR target is reached
> if recovery_target_time is specified.
>
> Missing WAL's could then be restored from backup and applied on next restart.
>
> Today PostgreSQL opens the database in re
This patch allows PostgreSQL to pause recovery before PITR target is reached
if recovery_target_time is specified.
Missing WAL's could then be restored from backup and applied on next restart.
Today PostgreSQL opens the database in read/write on a new timeline even when
PITR tareg is not reache
25 matches
Mail list logo
