| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
| Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, 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 11:59:45 |
| Message-ID: | 20180804115945.k54bivte737gkicv@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On 2018-08-04 10:54:22 +0100, Simon Riggs wrote:
> On 4 August 2018 at 07:56, Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> >> 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.
>
> pg_rewind doesn't work correctly. Documenting a workaround doesn't change that.
Especially because most people will only understand this after they've
been hit, as test scenarios will often just be quick enough.
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2018-08-04 13:13:12 | Re: Pg_rewind cannot load history wal |
| Previous Message | Simon Riggs | 2018-08-04 09:54:22 | Re: Pg_rewind cannot load history wal |