> On 7 Mar 2023, at 08:33, Alexander Kukushkin wrote:
> The "log_directory" GUC must be examined on both, source and target.
Agreed, log_directory must be resolved to the configured values. Teaching
pg_rewind about those in case they are stored in $PGDATA sounds like a good
idea though.
--
On Tue, 7 Mar 2023 at 08:52, Soumyadeep Chakraborty <
soumyadeep2...@gmail.com> wrote:
>
> > It couldn't be achieved just by introducing a static string "log". The
> "log_directory" GUC must be examined on both, source and target.
>
> Trouble with doing that is if pg_rewind is run in non-libpq
On Mon, Mar 6, 2023 at 11:33 PM Alexander Kukushkin wrote:
>
>
> Lets assume that on the source we have "pg_log" and on the target we have
> "my_log" (they are configured using "log_directory" GUC).
> When doing rewind in this case we want neither to remove the content of
> "my_log" on the
On Mon, 6 Mar 2023 at 19:37, Soumyadeep Chakraborty <
soumyadeep2...@gmail.com> wrote:
>
> > 2. Unlike "pg_wal", the "log" directory is not necessarily located
> inside PGDATA. The actual value is configured using "log_directory" GUC,
> which just happened to be "log" by default. And in fact
On Mon, Mar 6, 2023 at 12:28 AM Alexander Kukushkin wrote:
>
> Hello Soumyadeep,
>
> The problem indeed exists, but IMO the "log" directory case must be handled
> differently:
> 1. We don't need or I would even say we don't want to sync log files from the
> new primary, because it destroys the
Hello Soumyadeep,
The problem indeed exists, but IMO the "log" directory case must be handled
differently:
1. We don't need or I would even say we don't want to sync log files from
the new primary, because it destroys the actual logs, which could be very
important to figure out what has happened
