Re: Time-Delayed Standbys - Mailing list pgsql-hackers

From Fabrízio de Royes Mello
Subject Re: Time-Delayed Standbys
Date
Msg-id CAFcNs+r-GyizHAPDvRz=3XR3BYLUqxpqxrvJq8spk4PJe5hxAA@mail.gmail.com
Whole thread Raw
In response to Re: Time-Delayed Standbys  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Time-Delayed Standbys
List pgsql-hackers

On Fri, Dec 6, 2013 at 1:36 PM, Robert Haas <robertmhaas@gmail.com> wrote:
On Thu, Dec 5, 2013 at 11:07 PM, Fabrízio de Royes Mello
<fabriziomello@gmail.com> wrote:
> On Tue, Dec 3, 2013 at 5:33 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
>>
>> > - compute recoveryUntilDelayTime in XLOG_XACT_COMMIT and
>> > XLOG_XACT_COMMIT_COMPACT checks
>>
>> Why just those? Why not aborts and restore points also?
>>
>
> I think make no sense execute the delay after aborts and/or restore points,
> because it not change data in a standby server.

I see no reason to pause for aborts.  Aside from the fact that it
wouldn't be reliable in corner cases, as Fabrízio says, there's no
user-visible effect, just as there's no user-visible effect from
replaying a transaction up until just prior to the point where it
commits (which we also do).

Waiting for restore points seems like it potentially makes sense.  If
the standby is delayed by an hour, and you create a restore point and
wait 55 minutes, you might expect that that you can still kill the
standby and recover it to that restore point.


Makes sense. Fixed.

Regards,

--
Fabrízio de Royes Mello
Consultoria/Coaching PostgreSQL
Attachment

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: pg_archivecleanup bug
Next
From: Tom Lane
Date:
Subject: Re: Proof of concept: standalone backend with full FE/BE protocol