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
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 |