On Mon, Aug 3, 2015 at 1:30 AM, Tom Lane wrote:
> I haven't looked to find out why the unlinks happen in this order, but on
> a heavily loaded machine, it's certainly possible that the process would
> lose the CPU after unlink("postmaster.pid"), and then a new postmaster
> could get far enough to
I wrote:
> Further experimentation says that 9.0-9.2 do this in the expected order;
> so somebody broke it during 9.3.
Depressingly enough, the somebody was me. Fixed now.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make c
I wrote:
> unlink("/tmp/.s.PGSQL.5432")= 0
> unlink("postmaster.pid")= 0
> unlink("/tmp/.s.PGSQL.5432.lock") = 0
> exit_group(0) = ?
> +++ exited with 0 +++
> I haven't looked to find out why the unlinks happen in this order, but on
> a h
Observe the smoking gun at
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=mule&dt=2015-08-02%2003%3A30%3A02
to wit this extract from pg_upgrade_server.log:
command:
"/home/pg/build-farm-4.15.1/build/HEAD/pgsql.build/src/bin/pg_upgrade/tmp_check/install//home/pg/build-farm-4.15.1/build/HE
