From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Aleš Zelený <zeleny(dot)ales(at)gmail(dot)com> |
Cc: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: Wall shiping replica failed to recover database with error: invalid contrecord length 1956 at FED/38FFE208 |
Date: | 2019-10-02 22:09:15 |
Message-ID: | 20191002220914.GS6962@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Greetings,
* Aleš Zelený (zeleny(dot)ales(at)gmail(dot)com) wrote:
> But recovery on replica failed to proceed WAL file
> 0000000100000FED00000039 with log message: " invalid contrecord length
> 1956 at FED/38FFE208".
Err- you've drawn the wrong conclusion from that message (and you're
certainly not alone- it's a terrible message and we should really have a
HINT there or something). That's an INFO-level message, not an error,
and basically just means "oh, look, there's an invalid WAL record, guess
we got to the end of the WAL available from this source." If you had
had primary_conninfo configured in your recovery.conf, PG would likely
have connected to the primary and started replication. One other point
is that if you actually did a promotion in this process somewhere, then
you might want to set recovery_target_timeline=latest, to make sure the
replica follows along on the timeline switch that happens when a
promotion happens.
Thanks,
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Glenn Pierce | 2019-10-02 22:30:19 | performance of pg_upgrade "Copying user relation files" |
Previous Message | Stephen Frost | 2019-10-02 21:57:47 | Re: Performance on JSONB select |