Re: FATAL: bogus data in lock file "postmaster.pid": "" - Mailing list pgsql-hackers

From Michael Beattie
Subject Re: FATAL: bogus data in lock file "postmaster.pid": ""
Date
Msg-id CAJ=Gs0Kjw9iEnuxOL6J_8NvR6SH6rrsSbL9Gy1t_-pFKNR8dtg@mail.gmail.com
Whole thread Raw
In response to Re: FATAL: bogus data in lock file "postmaster.pid": ""  (Magnus Hagander <magnus@hagander.net>)
Responses Re: FATAL: bogus data in lock file "postmaster.pid": ""  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
On Fri, Jan 6, 2012 at 6:13 AM, Magnus Hagander <magnus@hagander.net> wrote:
On Thu, Jan 5, 2012 at 23:19, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Magnus Hagander <magnus@hagander.net> writes:
>> On Thu, Jan 5, 2012 at 17:13, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> I think link(2) would create race conditions of its own.  I'd be
>>> inclined to suggest that maybe we should just special-case a zero length
>>> postmaster.pid file as meaning "okay to proceed".  In general, garbage
>
>> That's pretty much what I meant - but with a warning message.
>
> Actually ... wait a minute.  If we allow that, don't we create a race
> condition between two postmasters starting at almost the same instant?
> The second one could see the lock file when the first has created but
> not yet filled it.

Good point, yeah, it should do that. But I still think it's rare
enough that just special-casing the error message should be enough...


so just something that does like

stat(filename, &st);
size = st.st_size;
if (size == 0)
   elog(ERROR, "lock file \"%s\" has 0 length.", filename);

somewhere in CreateLockFile in miscinit.c? 

 

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Unlogged tables and BufferSync()
Next
From: Andrew Dunstan
Date:
Subject: Re: [COMMITTERS] pgsql: Fix breakage from earlier plperl fix.