Re: Proposal: pg_rewind to skip config files

From: Vladimir Borodin <root(at)simply(dot)name>
To: Chris Travers <chris(dot)travers(at)adjust(dot)com>
Cc: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Proposal: pg_rewind to skip config files
Date: 2017-09-05 10:54:13
Message-ID: C961CFCE-55C4-4F60-891D-CCE0CBA12BCF@simply.name
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


> 5 сент. 2017 г., в 12:31, Chris Travers <chris(dot)travers(at)adjust(dot)com> написал(а):
>
> I think the simplest solution for now is to skip any files ending in .conf, .log, and serverlog.

Why don’t you want to solve the problem once? It is a bit harder to get consensus on a way how to do it, but it seems that there are no reasons to make temporary solution here.

For example, in archive_command we put WALs for archiving from pg_xlog/pg_wal into another directory inside PGDATA and than another cron task makes real archiving. This directory ideally should be skipped by pg_rewind, but it would not be handled by proposed change.

>
> Long run, it would be nice to change pg_rewind from an opt-out approach to an approach of processing the subdirectories we know are important.

While it is definitely an awful idea the user can easily put something strange (i.e. logs) to any important directory in PGDATA (i.e. into base or pg_wal). Or how for example pg_replslot should be handled (I asked about it a couple of years ago [1])? It seems that a glob/regexp for things to skip is a more universal solution.

[1] https://www.postgresql.org/message-id/flat/8DDCCC9D-450D-4CA2-8CF6-40B382F1F699%40simply.name

--
May the force be with you…
https://simply.name

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Konstantin Knizhnik 2017-09-05 10:58:56 Re: JIT compiling expressions/deform + inlining prototype v2.0
Previous Message Jeevan Chalke 2017-09-05 10:32:57 Re: Replacing lfirst() with lfirst_node() appropriately in planner.c