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 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 see the socket lock file still there. So that
> would account for low-probability failures in the pg_upgradecheck test,
> which is exactly what we've been seeing.
Further experimentation says that 9.0-9.2 do this in the expected order;
so somebody broke it during 9.3.
The lack of a close() on the postmaster socket goes all the way back
though.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
