Hi,
On Fri, Apr 05, 2019 at 04:56:32PM +0900, Michael Paquier wrote:
> On Fri, Apr 05, 2019 at 09:41:58AM +0200, Michael Banck wrote:
> > Is there a good reason why Postgres doesn't just issue a CHECKPOINT
> > after promote itself? After all, this seems to be about making the
> > control file having the proper content, which sounds like a good thing
> > to have in general.
>
> The startup process requests a checkpoint since 9.3, and before that
> it was doing the checkpoint by itself (grep for fast_promoted and
> RequestCheckpoint() around line 7579 in xlog.c). This allows the
> recovery to finish much faster.
Ok, so the problem is that that checkpoint might be still ongoing when
you quickly issue a pg_rewind from the other side? If not, can you
explain once more the actual problem?
In any case, the updated documentation says:
|When executing pg_rewind using an online cluster as source which has
|been recently promoted, it is necessary to execute a CHECKPOINT after
|promotion so as its control file reflects up-to-date timeline
|information
I think it might be useful to specify more exactly which of the two
servers (the remote one AIUI) needs a CHECKPOINT in the abvoe. Also, if
it is the case that a CHECKPOINT is done automatically (see above), that
paragraph could be rewritten to say something like "pg_rewind needs to
wait for the checkoint on the remote server to finish. This can be
ensured by issueing an explicit checkpoint on the remote server prior to
running pg_rewind."
Finally, (and still, if I got the above correctly), to the suggestion of
Magnus of pg_rewind running the checkpoint itself on the remote: would
that again mean that pg_rewind needs SUPERUSER rights or is there
a(nother) GRANTable function that could be added to the list in this
case?
Sorry for being a bit dense here.
Michael