Re: pg_rewind vs superuser

From: Michael Banck <mbanck(at)gmx(dot)net>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: pg_rewind vs superuser
Date: 2019-04-05 08:39:26
Message-ID: 20190405083925.GC15809@nighthawk.caipicrew.dd-dns.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2019-04-05 09:05:02 Re: Using condition variables to wait for checkpoints
Previous Message Kyotaro HORIGUCHI 2019-04-05 08:32:12 Re: Protect syscache from bloating with negative cache entries