Re: Proposal: pg_rewind to skip config files

From: Chris Travers <chris(dot)travers(at)adjust(dot)com>
To: Sokolov Yura <y(dot)sokolov(at)postgrespro(dot)ru>
Cc: PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>, pgsql-hackers-owner(at)postgresql(dot)org
Subject: Re: Proposal: pg_rewind to skip config files
Date: 2017-09-04 10:28:26
Message-ID: CAN-RpxA_rO+uPnUVMKpsMpWZGbFbiaaX+UouQncXSHqEQStPEA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Ok so I have a proof of concept patch here.

This is proof of concept only. It odes not change documentation or the
like.

The purpose of the patch is discussion on the "do we want this" side.

The patch is fairly trivial but I have not added test cases or changed docs
yet.

Intention of the patch:
pg_rewind is an important backbone tool for recovering data directories
following a switchover. However currently it is over inclusive as to what
it copies. This patch excludes any file ending in "serverlog", ".conf",
and ".log" because these are never directly related and add a great deal of
complexity to switchovers.

.conf files are excluded for two major reasons. The first is that often we
may want to put postgresql.conf and other files in the data directory, and
if we change these during switchover this can change, for example, the port
the database is running on or other things that can break production or
testing environments. This is usually a problem with testing environments,
but it could happen with production environments as well.

A much larger concern with .conf files though is the recovery.conf. This
file MUST be put in the data directory, and it helps determine the
replication topology regarding cascading replication and the like. If you
rewind from an upstream replica, you suddenly change the replication
topology and that can have wide-ranging impacts.

I think we are much better off insisting that .conf files should be copied
separately because the scenarios where you want to do so are more limited
and the concern often separate from rewinding the timeline itself.

The second major exclusion added are files ending in "serverlog" and
".log." I can find no good reason why server logs from the source should
*ever* clobber those on the target. If you do this, you lose historical
information relating to problems and introduce management issues.

Backwards-incompatibility scenarios:
If somehow one has a workflow that depends on copying .conf files, this
would break that. I cannot think of any cases where anyone would actually
want to do this but that doesn't mean they aren't out there. If people
really want to, then they need to copy the configuration files they want
separately.

Next Steps:

If people like this idea I will add test cases and edit documentation as
appropriate.

--
Best Regards,
Chris Travers
Database Administrator

Tel: +49 162 9037 210 | Skype: einhverfr | www.adjust.com
Saarbrücker Straße 37a, 10405 Berlin

Attachment Content-Type Size
pg_rewind_log_conf_patch.patch application/octet-stream 982 bytes

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Chris Travers 2017-09-04 10:31:07 Re: Proposal: pg_rewind to skip config files
Previous Message Michael Paquier 2017-09-04 10:23:03 Re: Proposal: pg_rewind to skip config files