| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
| Cc: | Richard Schmidt <Richard(dot)Schmidt(at)metservice(dot)com>, "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Pg_rewind cannot load history wal |
| Date: | 2018-08-04 06:56:54 |
| Message-ID: | 20180804065654.GF20967@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Sat, Aug 04, 2018 at 07:44:59AM +0100, Simon Riggs wrote:
> I think the problem is that writing the online checkpoint is deferred
> after promotion, so this is a timing issue that probably doesn't show
> in our regression tests.
Somewhat. It is a performance improvement of 9.3 to let the startup
request a checkpoint to the checkpointer process instead of doing it
itself.
> Sounds like we should write a pending timeline change to the control
> file and have pg_rewind check that instead.
>
> I'd call this a timing bug, not a doc issue.
Well, having pg_rewind enforce a checkpoint on the promoted standby
could cause a performance hit as well if we do it mandatorily as if
there is delay between the promotion and the rewind triggerring a
checkpoint could have already happen. So it is for me a documentation
bug first regarding the failover workflow, and potentially a patch for a
new feature which makes pg_rewind trigger directly a checkpoint.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2018-08-04 09:54:22 | Re: Pg_rewind cannot load history wal |
| Previous Message | Simon Riggs | 2018-08-04 06:44:59 | Re: Pg_rewind cannot load history wal |