Re: Inconvenience of pg_read_binary_file() - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Inconvenience of pg_read_binary_file()
Date
Msg-id 342893.1659191079@sss.pgh.pa.us
Whole thread Raw
In response to Inconvenience of pg_read_binary_file()  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Responses Re: Inconvenience of pg_read_binary_file()
List pgsql-hackers
Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> On 2022-Jul-30, Michael Paquier wrote:
>> PG_VERSION would be simpler.  Looking at postmaster.pid would require
>> a lookup at external_pid_file, and as it is not set by default you
>> would need to add some extra logic in the tests where
>> external_pid_file = NULL <=> PGDATA/postmaster.pid.

> Hmm, no? as I recall external_pid_file is an *additional* PID file; it
> doesn't supplant postmaster.pid.

Right.  postmaster.pid absolutely should be there if the postmaster
is up (and if it ain't, you're going to have lots of other difficulty
in running the regression tests...).  It doesn't feel quite as static
as PG_VERSION, though.

            regards, tom lane



pgsql-hackers by date:

Previous
From: "houzj.fnst@fujitsu.com"
Date:
Subject: RE: Functions 'is_publishable_class' and 'is_publishable_relation' should stay together.
Next
From: Tom Lane
Date:
Subject: Re: standby recovery fails (tablespace related) (tentative patch and discussion)