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

From Bruce Momjian
Subject Re: FATAL: bogus data in lock file "postmaster.pid": ""
Date
Msg-id 20120829022127.GA26103@momjian.us
Whole thread Raw
In response to Re: FATAL: bogus data in lock file "postmaster.pid": ""  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: FATAL: bogus data in lock file "postmaster.pid": ""
Re: FATAL: bogus data in lock file "postmaster.pid": ""
List pgsql-hackers
On Tue, Aug 28, 2012 at 04:25:36PM -0400, Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > Updated patch attached which just reports the file as empty.  I assume
> > we don't want the extra text output for pg_ctl like we do for the
> > backend.
>
> The backend side of this looks mostly sane to me (but drop the \n,
> messages are not supposed to contain those).  But the feof test proposed

Removed.  I thought we needed to add \n so that strings >80 would wrap
properly.  How do we handle this?

> for pg_ctl is no good: consider a file containing just, say, "-".
> fscanf would eat the "-", then hit eof, and this would complain the file
> is empty.  Possibly checking for ftell(pidf) == 0 would do, though I'm
> not sure whether it's portable to assume fscanf would eat a non-numeric
> character before complaining.

ftell() seems to work fine when combined with feof(), so I used that in
the attached patch.  ftell() alone remains at zero if the file contains
"A", so feof() is also needed.

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: A note about add_path() and parameterized paths
Next
From: Tom Lane
Date:
Subject: Re: FATAL: bogus data in lock file "postmaster.pid": ""