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

From Kyotaro Horiguchi
Subject Re: Inconvenience of pg_read_binary_file()
Date
Msg-id 20220801.174148.1664369784655078240.horikyota.ntt@gmail.com
Whole thread Raw
In response to Re: Inconvenience of pg_read_binary_file()  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
At Sat, 30 Jul 2022 10:24:39 -0400, Tom Lane <tgl@sss.pgh.pa.us> wrote in 
> 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.

Thanks for committing it.  Also the revised test (being suggested by
Michael) looks good.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



pgsql-hackers by date:

Previous
From: Peter Smith
Date:
Subject: Re: Handle infinite recursion in logical replication setup
Next
From: Amit Kapila
Date:
Subject: Re: Handle infinite recursion in logical replication setup