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
