From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
To: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
Cc: | Magnus Hagander <magnus(at)hagander(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Stephen Frost <sfrost(at)snowman(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Include WAL in base backup |
Date: | 2011-01-30 18:58:15 |
Message-ID: | 4D45B4C7.3040804@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 29.01.2011 09:10, Fujii Masao wrote:
> On Sat, Jan 29, 2011 at 6:02 AM, Heikki Linnakangas
> <heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
>> On 27.01.2011 06:44, Fujii Masao wrote:
>>>
>>> + XLByteToSeg(endptr, endlogid, endlogseg);
>>> <snip>
>>> + /* Have we reached our stop position yet? */
>>> + if (logid> endlogid ||
>>> + (logid == endlogid&& logseg>= endlogseg))
>>> + break;
>>>
>>> What I said in upthread is wrong. We should use XLByteToPrevSeg
>>> for endptr and check "logseg> endlogseg". Otherwise, if endptr is
>>> not a boundary byte, endlogid/endlogseg indicates the last
>>> necessary WAL file, but it's not sent.
>>
>> We should use XLByteToPrevSeg, but I believe>= is still correct.
>> logid/logseg is the last WAL segment we've successfully sent, and
>> endlogif/endlogid is the last WAL segment we need to send. When they are the
>> same, we're done.
>
> Really? logid/logseg is incremented just before the check as follows.
> So, when they are the same, the WAL file which logid/logseg indicates
> has not been sent yet. Am I missing something?
>
> + /* Advance to the next WAL file */
> + NextLogSeg(logid, logseg);
> +
> + /* Have we reached our stop position yet? */
> + if (logid> endlogid ||
> + (logid == endlogid&& logseg>= endlogseg))
> + break;
Ah, you're right, I misread it. Never mind..
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-01-30 19:11:01 | Re: multiset patch review |
Previous Message | Heikki Linnakangas | 2011-01-30 18:56:06 | Re: REVIEW: Determining client_encoding from client locale |