From: | Dmitry Kovalenko <d(dot)kovalenko(at)postgrespro(dot)ru> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #18971: Server passes an invalid (indirect) path in PGDATA to the external program |
Date: | 2025-06-28 19:32:59 |
Message-ID: | ec6c6594-8b0f-487d-a1e9-9f9f456bf573@postgrespro.ru |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Hello Tom,
> I do not think this is a Postgres bug. The PGDATA environment
> variable is not canonical, it is just the default to be used if
> you don't specify a -D switch on the postmaster/pg_ctl command line.
> In fact, it might not be set at all. (I see that pg_ctl does set
> it, but pg_ctl is not the only way to start the postmaster.)
> Therefore, relying on PGDATA in a restore_command script isn't safe.
> You should be relying on the current working directory (PWD) instead.
A test executes pg_ctl with the correct path to cluster and the correct CWD.
pg_ctl (and so on) executes an external program with inconsistent PGDATA
and CWD.
This is clearly a problem on your side )
I wonder that it was not detected earlier.
For my point of view, if you can't provider a valid path in PGDATA, do
not do it at all.
With Best Regards,
Dmitry Kovalenko
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2025-06-28 20:19:13 | Re: BUG #18971: Server passes an invalid (indirect) path in PGDATA to the external program |
Previous Message | Tom Lane | 2025-06-28 19:13:25 | Re: BUG #18971: Server passes an invalid (indirect) path in PGDATA to the external program |