Re: Standby trying "restore_command" before local WAL

Greetings,

* David Steele (david(at)pgmasters(dot)net) wrote:
> I think for the stated scenario (known good standby that has been
> shutdown gracefully) it makes perfect sense to trust the contents of
> pg_wal. Call this scenario #1.
>
> An alternate scenario (#2) is that the data directory was copied using a
> basic copy tool and the pg_wal directory was not excluded from the copy.
> This means the contents of pg_wal will be in an inconsistent state.
> The files that are there might be partials (not with the extension,
> though) and you can easily have multiple partials. You will almost
> certainly not have everything you need to get to consistency.
>
> But there's another good scenario (#3): where the pg_wal directory was
> preloaded with all the WAL required to make the cluster consistent or
> all the WAL that was available at restore time. In this case, it would
> be make sense to prefer the contents of pg_wal and only switch to
> restore_command after that has been exhausted.
>
> So, the choice of whether to prefer locally-stored or
> restore_command-fetched WAL is context-dependent, in my mind.

Agreed.

> Ideally we could have a default that is safe in each scenario with
> perhaps an override if the user knows better. Scenario #1 would allow
> WAL to be read from pg_wal by default, scenario #2 would prefer fetched
> WAL, and scenario #3 could use a GUC to override the default fetch behavior.

Not sure how we'd be able to automatically realize which scenario we're
in though..?

Thanks!

Stephen