From: | Alexander Kukushkin <cyberdemn(at)gmail(dot)com> |
---|---|
To: | Aleksander Alekseev <aleksander(at)timescale(dot)com> |
Cc: | Gunnar Nick Bluth <gunnar(dot)bluth(at)pro-open(dot)de>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: PATCH: add "--config-file=" option to pg_rewind |
Date: | 2022-02-24 09:27:30 |
Message-ID: | CAFh8B=mR--gD0hMgn3a2ygLoen-ZkY2k=pJoLcvDToiUUQJ-ug@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello Gunnar,
On Thu, 24 Feb 2022 at 10:03, Aleksander Alekseev <aleksander(at)timescale(dot)com>
wrote:
> > wants to use the "-c" option on a typical Debian/Ubuntu installation
> > (where the config resides below /etc/postgresql/), pg_rewind needs a way
> > to be told where the postgresql.conf actually is.
> >
> > The attached patch implements this as an option.
> >
> > [...]
>
> Good catch!
>
Yeah, it is a known problem, and there was already another patch trying to
address it [1].
Honestly, I like your approach much better, because, the previous make was
assuming that the data_directory GUC is specified in the postgresql.conf,
which is not very flexible.
>
> Could you also implement a TAP test for the new code?
>
+1
+ <para>
+ In case the <filename>postgresql.conf</filename> of your target
cluster is not in the
+ target pgdata and you want to use the <option>-c</option> option,
+ provide a (relative or absolute) path to the
<filename>postgresql.conf</filename> using this option.
+ </para>
It took me a while to understand the meaning of <option>-c</option>. Maybe
changing it to <option>--restore-target-wal</option> will make it easier to
understand.
[1]
https://www.postgresql.org/message-id/flat/16982-f12294cccd221480%40postgresql.org
Regards,
--
Alexander Kukushkin
From | Date | Subject | |
---|---|---|---|
Next Message | Tatsuo Ishii | 2022-02-24 09:38:57 | Re: Typo in pgbench messages. |
Previous Message | Peter Eisentraut | 2022-02-24 09:20:39 | Re: Design of pg_stat_subscription_workers vs pgstats |