Re: Explanation for intermittent buildfarm pg_upgradecheck failures - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Explanation for intermittent buildfarm pg_upgradecheck failures
Date
Msg-id CAB7nPqRQUd8Nh+KEimB+Oqx25zYamJuVHVwrjhZ3Vgk_8ax+iw@mail.gmail.com
Whole thread Raw
In response to Explanation for intermittent buildfarm pg_upgradecheck failures  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, Aug 3, 2015 at 1:30 AM, Tom Lane <tgl@sss.pgh.pa.us> 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 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.

Oh... This may explain the different failures seen with TAP tests on
hamster, and axolotl with pg_upgrade as well. It is rather easy to get
them heavily loaded.
-- 
Michael



pgsql-hackers by date:

Previous
From: Kouhei Kaigai
Date:
Subject: Re: nodes/*funcs.c inconsistencies
Next
From: Michael Paquier
Date:
Subject: Re: Improving test coverage of extensions with pg_dump