Re: Wall shiping replica failed to recover database with error:invalid contrecord length 1956 at FED/38FFE208

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: Wall shiping replica failed to recover database with error:invalid contrecord length 1956 at FED/38FFE208
Дата
Msg-id 20191002220914.GS6962@tamriel.snowman.net
обсуждение исходный текст
Ответ на Wall shiping replica failed to recover database with error: invalidcontrecord length 1956 at FED/38FFE208  (Aleš Zelený <zeleny.ales@gmail.com>)
Ответы Re: Wall shiping replica failed to recover database with error: invalid contrecord length 1956 at FED/38FFE208  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Wall shiping replica failed to recover database with error:invalid contrecord length 1956 at FED/38FFE208  (Aleš Zelený <zeleny.ales@gmail.com>)
Список pgsql-general
Greetings,

* Aleš Zelený (zeleny.ales@gmail.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

Вложения

В списке pgsql-general по дате отправления:

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: Performance on JSONB select
Следующее
От: Glenn Pierce
Дата:
Сообщение: performance of pg_upgrade "Copying user relation files"