On Wed, Mar 28, 2018 at 12:23:31PM -0700, Keiko Oda wrote:
> Thanks a lot for the answer, Michael (and sorry for the slow response)!
No problem.
> So, if I understand what you're saying correctly, I'm seeing this behavior
> because wal-e keeps fetching wal files from s3 regardless of this
> trigger_file, and these fetched wal files are in pg_wal (or pg_xlog),
> therefore Postgres just tries to restore whatever available in pg_wal
> before the failover. Or, even if there is no file in pg_wal, it still tries
> to fetch from the "archive" (s3).
> In other words, if I would like to do "immediate failover" (and do not care
> about WAL files available in archive or in pg_wal), I should be tweaking
> restore_command so that no further fetching/restoring happens.
> Is it... accurate?
Per the code and the documentation, the current behavior is clearly
intentional. If you think about it, it can be relatively important
especially in the case of a base backup taken without WAL segments in
pg_wal while relying on a separate archive: this gives more guarantees
that the consistent point will be reached. That also covers a bit what
people can look for in some cases with recovery_target = 'immediate'.
You could indeed tweak the restore command. If a failure happens while
attempting to fetch a WAL segment, then the recovery would immediately
stop. If you try to trigger a promotion without reaching a consistency
point, then you would get a complain from the startup process. There
are some safeguards for this purpose.
Please don't take me wrong. There is room for a feature which does more
efficiently what you are looking for, but that would be a separate
problem.
(Sakura season here by the way, they are blooming this week)
--
Michael
