Re: Warm standby problems: Followup - Mailing list pgsql-admin

From David F. Skoll
Subject Re: Warm standby problems: Followup
Date
Msg-id 4AE74A7B.4030406@roaringpenguin.com
Whole thread Raw
In response to Re: Warm standby problems: Followup  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Warm standby problems: Followup
List pgsql-admin
Tom Lane wrote:

> So, when it archives successfully the second time, which if either of
> the two mismatched sha1's proves to have been correct?

The one on the master server (lines wrapped for readability).
"local" refers to the master server, and "remote" to the standby
server.

Oct 27 14:26:35 colo2vs1 canit-failover-wal-archive[29118]: Warning:
rsync succeeded, but local_sha1
1fe9fc62b2a05d21530decac1c5442969adc5819 !=
remote_sha1 4f9f8bcd151129db64acd05470f0f05954b56232 !!

Oct 27 14:26:52 colo2vs1 canit-failover-wal-archive[29161]: local_sha1 ==
remote_sha1 (1fe9fc62b2a05d21530decac1c5442969adc5819)

Oct 27 14:26:53 colo2vs1 canit-failover-wal-archive[29161]:
Successfully archived WAL file 000000010000001200000058 on
colo3vs1.roaringpenguin.com

However, the sha1 is taken after rsync exits, so it's unknown what
the local sha1 actually was while the rsync was running.  Maybe the
sha1 really was 4f9... on the master server until something changed
the file.

> (I'm still wondering about the possibility that the WAL file is changing
> underneath you ...)

Well, can PostgreSQL change the WAL file while the archive_command is
running?  I can't see anything on the backup server end changing that
copy.

Regards,

David.

pgsql-admin by date:

Previous
From: Tom Lane
Date:
Subject: Re: Warm standby problems: Followup
Next
From: "Kevin Grittner"
Date:
Subject: Re: Warm standby problems: Followup