On Thu, Jun 10, 2010 at 4:07 PM, Heikki Linnakangas <heikki.linnakan...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers