Re: Standby trying "restore_command" before local WAL - Mailing list pgsql-hackers

From Sergei Kornilov
Subject Re: Standby trying "restore_command" before local WAL
Date
Msg-id 27173531533055165@sas2-5d23d1328f85.qloud-c.yandex.net
Whole thread Raw
In response to Re: Standby trying "restore_command" before local WAL  (Stephen Frost <sfrost@snowman.net>)
Responses Re: Standby trying "restore_command" before local WAL
List pgsql-hackers
Hello

> As mentioned by others, it sounds like we could have an option to try
> contacting the primary before running restore_commnad
Why about primary?
If we have restore_command on slave (or during point in time recovery) - we force using XLOG_FROM_ARCHIVE, even if
XLOG_FROM_PG_WALsource can provide next WAL. As say xlog.c comment [1]:
 

> * We just successfully read a file in pg_wal. We prefer files in
> * the archive over ones in pg_wal, so try the next file again
> * from the archive first.

We have some actual reason why we prefer restore_command instead of using local wal files first?
Partially written WAL? Streaming replication can leave partially written WAL and we can handle this correctly.

Later (in XLogFileReadAnyTLI caller) we change XLOG_FROM_ARCHIVE to XLOG_FROM_ANY, but we force call XLOG_FROM_ARCHIVE
firstand then look in XLOG_FROM_PG_WAL. Or i am wrong?
 

regards, Sergei

[1]
https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/access/transam/xlog.c;h=493f1db7b97a94b882382fc3d2112634f56c86a3;hb=refs/heads/master#l12113


pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Standby trying "restore_command" before local WAL
Next
From: "Jonathan S. Katz"
Date:
Subject: PostgreSQL 11 Beta 3 Release: 2018-08-09