From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Fabrízio Mello <fabriziomello(at)gmail(dot)com> |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>, KONDO Mitsumasa <kondo(dot)mitsumasa(at)lab(dot)ntt(dot)co(dot)jp> |
Subject: | Re: Time-Delayed Standbys |
Date: | 2013-12-06 15:36:18 |
Message-ID: | CA+TgmoaCL4G+YotjjjFM+J_h0nSkp4gXiiBPDQGHxTcc_T0w-w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Dec 5, 2013 at 11:07 PM, Fabrízio de Royes Mello
<fabriziomello(at)gmail(dot)com> wrote:
> On Tue, Dec 3, 2013 at 5:33 PM, Simon Riggs <simon(at)2ndquadrant(dot)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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2013-12-06 15:45:40 | Re: pg_archivecleanup bug |
Previous Message | Tom Lane | 2013-12-06 15:24:00 | Re: Re: [RFC] Shouldn't we remove annoying FATAL messages from server log? |