On Thu, Jun 10, 2010 at 4:07 PM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
> Ah, I just committed a patch to do the same, before seeing your email.
> Thanks anyway.
Yeah, thanks a lot!
> 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);
> 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;
> }
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center