Re: [HACKERS] Proposal: pg_rewind to skip config files
От | Vladimir Borodin |
---|---|
Тема | Re: [HACKERS] Proposal: pg_rewind to skip config files |
Дата | |
Msg-id | 50BB4E3A-B3CD-49C4-8AA3-DA2036C867A1@simply.name обсуждение исходный текст |
Ответ на | Re: [HACKERS] Proposal: pg_rewind to skip config files (Chris Travers <chris.travers@adjust.com>) |
Список | pgsql-hackers |
5 сент. 2017 г., в 15:42, Chris Travers <chris.travers@adjust.com> написал(а):On Tue, Sep 5, 2017 at 2:40 PM, Vladimir Borodin <root@simply.name> wrote:5 сент. 2017 г., в 14:04, Michael Paquier <michael.paquier@gmail.com> написал(а):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.
I would be curious to follow the reasoning for such a two-phase
archiving (You basically want to push it in two places, no? But why
not just use pg_receivexlog then?). This is complicated to handle from
the point of view of availability and backup reliability + durability.We do compress WALs and send them over network. Doing it via archive_command in single thread is sometimes slower than new WALs are written under heavy load.How would this work when it comes to rewinding against a file directory?
Very bad, of course. Sometimes we get 'could not remove file "/var/lib/postgresql/9.6/data/wals/00000001000000C3000000C6": No such file or directory’ while running pg_rewind ($PGDATA/wals is a directory where archive_command copies WALs). That’s why I want to solve the initial problem. Both proposed solutions (using only needed files and skipping files through glob/regex) are fine for me, but not the initial patch.
В списке pgsql-hackers по дате отправления: