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
signature.asc
Description: PGP signature
