On Thu, Nov 30, 2017, at 00:22, Alvaro Herrera wrote:
> Alex Kliukin wrote:
>
> > 2017-11-15 13:15:46.673 CET,,,15154,,5a0c2ff1.3b32,5,,2017-11-15
> > 13:15:45 CET,,0,PANIC,XX000,"replication checkpoint has wrong magic
> > 5714534 instead of 307747550",,,,,,,,,""
>
> Uhh ... I had never heard of this "replication checkpoint" thing. It is
> part of replication origins feature, which is fairly new stuff (see
> src/backend/replication/logical/origin.c). I'd bet this problem is
> related to a bug in logical replication "origins" code rather than any
> procedural problems in your base-backup taking setup ...
We are not using logical replication or logical decoding on those hosts.
On the master, pg_replication_origin is empty as well as
pg_replication_slots
Those masters were fairly recently (around 2 months ago) upgraded from
9.3.
>
> I wonder if there is some truncation of the 0x1257DADE value that
> produces the 5714534 value you're seeing -- something related to a
> pg_logical/replorigin_checkpoint file being written partially while the
> backup is being taken.
307747550 = 0x1257DADE
0001 0010 0101 0111 1101 1010 1101 1110
5714534 = 0x573266 = w2f ASCII
0000 0000 0101 0111 0011 0010 0110 0110
I see no patterns here.
What is interesting is that 0x573266 is actually mentioned in relcache.c
#define RELCACHE_INIT_FILENAME "pg_internal.init"
#define RELCACHE_INIT_FILEMAGIC 0x573266 /* version ID
value */
it's a file magic for the relcache init files, but given that the copy
is performed by just compressing and decompressing the original files I
don't see how those 2 could be confused by software.
>
> Another point towards not including pg_logical/ contents when taking a
> base backup, I guess ...
In our case wouldn't it just mask the real issue?
--
Sincerely,
Alex
