Re: pg_rewind and postgresql.conf - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: pg_rewind and postgresql.conf
Date
Msg-id 20180504130248.GB1592@paquier.xyz
Whole thread Raw
In response to Re: pg_rewind and postgresql.conf  (Chris Travers <chris.travers@adjust.com>)
List pgsql-hackers
On Fri, May 04, 2018 at 02:05:25PM +0200, Chris Travers wrote:
> I totally agree.  Ideally, rewind would just rewind data dirs by default
> and provide an option to include other files as specified by the
> administrator.

That's actually a potential please-shoot-both-my-feet option.  Imagine
if one uses it for accidentally (or imagine reduce the amount of network
bandwidth) removing critical data like what's in pg_xact/...  So I am
not especially a fan of such options.

> There are two other things that would really be nice to make work too (but
> think that's another major version away):
>
> 1.  Make pg_rewind work over the replication protocol so it doesn't require
> db superuser

Actually, there is no need to use a superuser now for v11.  A user just
needs to be part of the system group pg_read_server_files.  Switching to
the replication protocol could introduce more bugs which are not worth
the risk.

> 2.  Unify, to the extent possible, the code base with pg_basebackup.

Yeah, that's what happened with 266b6ac.  You could unify things a bit
more by sharing the exclude filter lists now in basebackup.c and
filemap.c into a common header, but some variables are declared only on
backend-side code and I would love to avoid tweaks like in pg_resetwal
which include postgres.h and enforce FRONTEND to 1 without using
postgres_fe.h.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Christoph Moench-Tegeder
Date:
Subject: Re: pg_rewind and postgresql.conf
Next
From: Ildar Musin
Date:
Subject: MAP syntax for arrays