Re: [GENERAL] Shared WAL archive between master and standby: WALs notalways identical - Mailing list pgsql-general

From Jon Nelson
Subject Re: [GENERAL] Shared WAL archive between master and standby: WALs notalways identical
Date
Msg-id CAKuK5J3VBBX9_fV617ZDoNehL4U+z5kXFz55hv478jhHKy5vdg@mail.gmail.com
Whole thread Raw
In response to Re: [GENERAL] Shared WAL archive between master and standby: WALs notalways identical  (Adrian Klaver <adrian.klaver@aklaver.com>)
Responses Re: [GENERAL] Shared WAL archive between master and standby: WALs notalways identical  (Sasa Vilic <sasavilic@gmail.com>)
List pgsql-general


On Tue, Feb 28, 2017 at 9:41 AM, Adrian Klaver <adrian.klaver@aklaver.com> wrote:
On 02/27/2017 11:14 PM, Sasa Vilic wrote:
...
 
"My problem is that sometimes WAL uploaded from master and from slave are not 100% identical. In most cases they are but occasionally they are not. I have written small script that ensures that upload is free of race condition and I log md5 sum of each WAL."

The wisdom (or not!) in archiving WAL to the same location from multiple sources (even if they share a common ancestor) notwithstanding, I must admit to having my curiosity piqued. 

Let's assume a different situation:
- a master and one or more standby units each archiving every WAL file but to it's own archive
- we check to see if identically named WAL files are content identical

Does it surprise anybody else that, sometimes, an identically named WAL file from the master and from a standby have different contents?  It surprises me.

I would love to know if the differences are due to some oversight in the WAL archiving mechanism chosen by the OP or if, in fact, a master and a standby generate different WAL files!

What does pg_xlogdump say about the differences in the files?


--
Jon

pgsql-general by date:

Previous
From: Adrian Klaver
Date:
Subject: Re: [GENERAL] Shared WAL archive between master and standby: WALs notalways identical
Next
From: Adrian Klaver
Date:
Subject: Re: [GENERAL] ERROR: functions in index expression must be markedIMMUTABLE