Re: InvalidXLogRecPtr in docs - Mailing list pgsql-hackers

On 10/06/10 10:43, Fujii Masao wrote:
> On Thu, Jun 10, 2010 at 4:07 PM, Heikki Linnakangas
> <heikki.linnakangas@enterprisedb.com>  wrote:
>> BTW, the docs claim about pg_last_xlog_location() that "While streaming
>> replication is in progress this will increase monotonically." That's a bit
>> misleading: when the replication connection is broken for some reason and we
>> restart it, we begin streaming from the beginning of the last WAL segment.
>> So at that moment, pg_last_xlog_location() moves backwards to the beginning
>> of the WAL segment.
>>
>> 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.

>> 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.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com