Re: InvalidXLogRecPtr in docs

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Takahiro Itagaki <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: InvalidXLogRecPtr in docs
Date: 2010-06-10 08:37:06
Message-ID: AANLkTimWYdbtBimEfrp47NxqWKNsF4HGkJvIVL5zAq-T@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jun 10, 2010 at 5:04 PM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
>>> Should we:
>>> 1. Just document that,
>>> 2. Change pg_last_xlog_location() to not move backwards in that case, or
>>> 3. Change the behavior so that we start streaming at the exact byte
>>> location
>>> where we left off?
>>
>> I'm for 2 as follows.
>>
>> diff --git a/src/backend/replication/walreceiver.c
>> b/src/backend/replication/walreceiver.c
>> index 26aeca6..f0fd813 100644
>> --- a/src/backend/replication/walreceiver.c
>> +++ b/src/backend/replication/walreceiver.c
>> @@ -524,7 +524,8 @@ XLogWalRcvFlush(void)
>>
>>                 /* Update shared-memory status */
>>                 SpinLockAcquire(&walrcv->mutex);
>> -               walrcv->receivedUpto = LogstreamResult.Flush;
>> +               if (XLByteLT(walrcv->receivedUpto, LogstreamResult.Flush))
>> +                       walrcv->receivedUpto = LogstreamResult.Flush;
>>                 SpinLockRelease(&walrcv->mutex);
>
> That's not enough, because we set receivedUpto in RequestXlogStreaming()
> already.

Ah, you are right.

>>> I believe that starting from the beginning of the WAL segment is just
>>> paranoia, to avoid creating a WAL file that's missing some data from the
>>> beginning. Right?
>>
>> Only when the recovery starting record (i.e., the record at the checkpoint
>> redo location) is not found, we need to start replication from the
>> beginning
>> of the segment, I think. That is, fetching_ckpt = true case in the
>> following
>> code.
>>
>>> if (PrimaryConnInfo)
>>> {
>>>        RequestXLogStreaming(
>>>                fetching_ckpt ? RedoStartLSN : *RecPtr,
>>>                PrimaryConnInfo);
>>>        continue;
>>> }
>
> Even then, we wouldn't need to start from the beginning of the WAL segment
> AFAICS. The point is to start from the Redo pointer, not from the checkpoint
> record, because as soon as we read the checkpoint record we'll need to start
> applying WAL from the Redo pointer, which is earlier. The WAL file
> boundaries don't come into play there.

You mean that the WAL file containing the Redo pointer is guaranteed to exist
if we could read the checkpoint record, so we don't need to start from the
beginning of the segment? This is probably true. But what if we could not read
the checkpoint record? In this case, the WAL file containing the Redo pointer
also might not exist.

Regards,

--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2010-06-10 08:49:33 Re: LLVM / clang
Previous Message Devrim GÜNDÜZ 2010-06-10 08:29:58 Re: Large (almost 50%!) performance drop after upgrading to 8.4.4?