From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Chris Travers <chris(dot)travers(at)adjust(dot)com> |
Cc: | Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: pg_rewind and postgresql.conf |
Date: | 2018-05-04 13:02:48 |
Message-ID: | 20180504130248.GB1592@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Ildar Musin | 2018-05-04 13:08:03 | MAP syntax for arrays |
Previous Message | Christoph Moench-Tegeder | 2018-05-04 12:57:16 | Re: pg_rewind and postgresql.conf |