Re: Concurrency issue in pg_rewind
От | Alexander Kukushkin |
---|---|
Тема | Re: Concurrency issue in pg_rewind |
Дата | |
Msg-id | CAFh8B=kETf_7t8DuWoONH=vdG4pZBQxUz6RXkMUx2=WR62R-gw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Concurrency issue in pg_rewind (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: Concurrency issue in pg_rewind
|
Список | pgsql-hackers |
Hi, On Fri, 18 Sep 2020 at 08:59, Michael Paquier <michael@paquier.xyz> wrote: > If this stuff is willing to do so, you may have your reasons, but even > if you wish to locate both pg_wal/ and the prefetch path in the same > partition, I don't get why it is necessary to have the prefetch path > included directly in pg_wal? You could just use different paths for > both. Say, with a base partition at /my/path/, you can just have > /my/path/pg_wal/ that the Postgres backend links to, and > /my/path/wal-g/prefetch/ for the secondary path. Well, I agree and disagree at the same time. Yes, it would be nice not to write anything unexpected to PGDATA and pg_wal, but this is also a usability issue. Creating a separate directory and configuring wal-e/wal-g to use it (now it is not even possible to configure it), requires some effort from the administrator, while using something inside pg_wal just works. At the same time, pg_rewind due to such "fatal" error leaves PGDATA in an inconsistent state with empty pg_control file, this is totally bad and easily fixable. We want the specific file to be absent and it is already absent, why should it be a fatal error and not warning? Regards, -- Alexander Kukushkin
В списке pgsql-hackers по дате отправления: