Re: Trigger file behavior with the standby

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Keiko Oda <keiko713(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Trigger file behavior with the standby
Date: 2018-03-29 00:04:53
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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

(Sakura season here by the way, they are blooming this week)

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2018-03-29 00:05:27 Re: [bug fix] pg_rewind creates corrupt WAL files, and the standby cannot catch up the primary
Previous Message Michael Paquier 2018-03-28 23:55:39 Re: Using base backup exclusion filters to reduce data transferred with pg_rewind