Re: [HACKERS] Proposal: pg_rewind to skip config files
| От | Chris Travers |
|---|---|
| Тема | Re: [HACKERS] Proposal: pg_rewind to skip config files |
| Дата | |
| Msg-id | CAN-RpxAgRPSJE8m6N+Luhw1ew4t8KM_66Kfh8Y2b9K4kanmrOQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [HACKERS] Proposal: pg_rewind to skip config files (Vladimir Borodin <root@simply.name>) |
| Список | pgsql-hackers |
On Tue, Sep 5, 2017 at 12:54 PM, Vladimir Borodin <root@simply.name> wrote:
5 сент. 2017 г., в 12:31, Chris Travers <chris.travers@adjust.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.
Ok let's back up a bit in terms of what I see is the proper long-term fix. Simple code, by the way, is important, but at least as important are programs which solve simple, well defined problems. The current state is:
1. pg_rewind makes *no guarantee* as to whether differences in logs, config files, etc. are clobbered. They may (If a rewind is needed) or not (If the timelines haven't diverged). Therefore the behavior of these sorts of files with the invocation of pg_rewind is not really very well defined. That's a fairly big issue in an operational environment.
2. There are files which *may* be copied (I.e. are copied if the timelines have diverged) which *may* have side effects on replication topology, wal archiving etc. Replication slots, etc. are good examples.
The problem I think pg_rewind should solve is "give me a consistent data environment from the timeline on that server." I would think that access to the xlog/clog files would indeed be relevant to that. If I were rewriting the application now I would include those. Just because something can be handled separately doesn't mean it should be, and I would refer not to assume that archiving is properly set up and working.
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.
I am not convinced it is a universal solution unless you take an arbitrary number or regexes to check and loop through checking all of them. Then the chance of getting something catastrophically wrong in a critical environment goes way up and you may end up in an inconsistent state at the end.
Simple code is good. A program that solves simple problems reliably (and in simple ways) is better.
The problem I see is that pg_rewind gets incorporated into other tools which don't really provide the user before or after hooks and therefore it isn't really fair to say, for example that repmgr has the responsibility to copy server logs out if present, or to make sure that configuration files are not in the directory.
The universal solution is to only touch the files that we know are needed and therefore work simply and reliably in a demanding environment.
Best Regards,
Chris Travers
Database Administrator
Saarbrücker Straße 37a, 10405 Berlin
В списке pgsql-hackers по дате отправления:
Предыдущее
От: Ashutosh BapatДата:
Сообщение: Re: [HACKERS] no test coverage for ALTER FOREIGN DATA WRAPPER nameHANDLER ...
Следующее
От: Vladimir BorodinДата:
Сообщение: Re: [HACKERS] Proposal: pg_rewind to skip config files