Re: FATAL: bogus data in lock file "postmaster.pid": ""

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: FATAL: bogus data in lock file "postmaster.pid": ""
Date: 2012-01-05 14:28:30
Message-ID: CA+TgmoZW4H7W5-t5_iiGPaQ+0kgtXDSn5zf+mAoxQDRLmLkJpg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jan 5, 2012 at 8:23 AM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
> On Thu, Jan 5, 2012 at 14:18, Heikki Linnakangas
> <heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
>> My laptop ran out of battery and turned itself off while I was just starting
>> up postmaster. After plugging in the charger and rebooting, I got the
>> following error when I tried to restart PostgreSQL:
>>
>> FATAL:  bogus data in lock file "postmaster.pid": ""
>>
>> postmaster.pid file was present in the data directory, but had zero length.
>> Looking at the way the file is created and written, that can happen if you
>> crash after the file is created, but before it's written/fsync'd (my laptop
>> might have write-cache enabled, which would make the window larger).
>>
>> I was a bit surprised by that. That's probably not a big deal in practice,
>> but I wonder if there was some easy way to avoid that. First I thought we
>> could create the new postmaster.pid file with a temporary name and rename it
>> in place, but rename(2) will merrily overwrite any existing file which is
>> not what we want. We could use link(2), I guess.
>
> Is this really a problem big enough to spend even that much effort on?
>
> Perhaps a special-case in the error message instead is enough?

On a laptop it's not a big deal, but it sort of sucks if your
production database fails to start automatically after an unexpected
power outage.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2012-01-05 14:32:30 Re: random_page_cost vs seq_page_cost
Previous Message Robert Haas 2012-01-05 14:27:16 Re: Page Checksums + Double Writes