Message-ID: <ec6c6594-8b0f-487d-a1e9-9f9f456bf573@postgrespro.ru>
Date: Sat, 28 Jun 2025 22:32:59 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: BUG #18971: Server passes an invalid (indirect) path in PGDATA to
 the external program
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-bugs@lists.postgresql.org
References: <18971-53687392b125e4bf@postgresql.org>
 <2334360.1751138005@sss.pgh.pa.us>
Content-Language: ru, en-US
From: Dmitry Kovalenko <d.kovalenko@postgrespro.ru>
In-Reply-To: <2334360.1751138005@sss.pgh.pa.us>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/ec6c6594-8b0f-487d-a1e9-9f9f456bf573%40postgrespro.ru>
Precedence: bulk

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