Re: "pg_ctl: the PID file ... is empty" at end of make check - Mailing list pgsql-hackers

From Tom Lane
Subject Re: "pg_ctl: the PID file ... is empty" at end of make check
Date
Msg-id 12547.1543384034@sss.pgh.pa.us
Whole thread Raw
In response to Re: "pg_ctl: the PID file ... is empty" at end of make check  (Thomas Munro <thomas.munro@enterprisedb.com>)
Responses Re: "pg_ctl: the PID file ... is empty" at end of make check
List pgsql-hackers
Thomas Munro <thomas.munro@enterprisedb.com> writes:
> On Wed, Nov 28, 2018 at 5:28 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> So my theory is we broke something in HEAD a couple weeks ago.  But what?

> Hmm.  Not seeing it.  I'm trying to do it again, with a make check loop.

>> The fsync changes you made are suspiciously close to this issue (ie one
>> could explain it as written data not getting out), and were committed in
>> the right time frame, but that change didn't affect writes to
>> postmaster.pid did it?

> Commit 9ccdd7f6 doesn't affect writes to anything.  It just changes
> the elevel if certain fsync calls fail (and incidentally none near
> this code, and in any case there was no failure).

Yeah ... the other weird thing about this is that the postmaster log
shows normal shutdown.

Is it possible that unlink() on APFS is not atomic?  That is, the
sequence of events is something like

pg_ctl: open("postmaster.pid")
                                     postmaster: unlink("postmaster.pid")
pg_ctl: reads file, gets zero bytes

But that idea is in the OS-bug class, which we agree seems unlikely.

            regards, tom lane


pgsql-hackers by date:

Previous
From: Tatsuro Yamada
Date:
Subject: Re: Tab completion for ALTER INDEX|TABLE ALTER COLUMN SET STATISTICS
Next
From: Amit Langote
Date:
Subject: Re: Planning time of Generic plan for a table partitioned into a lot