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

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Michael Beattie <mtbeedee(at)gmail(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, 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-08-27 22:02:06
Message-ID: CA+TgmoaKDUfMQT7_uSNCcU92+CktvUy8RqvpXt=Qk+J=CJiV=Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Aug 27, 2012 at 4:29 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
>> I have developed the attached patch to report a zero-length file, as you
>> suggested.
>
> DIRECTORY_LOCK_FILE is entirely incorrect there.
>
> Taking a step back, I don't think this message is much better than the
> existing behavior of reporting "bogus data". Either way, it's not
> obvious to typical users what the problem is or what to do about it.
> If we're going to emit a special message I think it should be more user
> friendly than this.
>
> Perhaps something like:
>
> FATAL: lock file "foo" is empty
> HINT: This may mean that another postmaster was starting at the
> same time. If not, remove the lock file and try again.

The problem with this is that it gives the customer only one remedy,
which they will (if experience is any guide) try whether it is
actually correct to do so or not.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2012-08-27 22:06:42 Re: temporal support patch
Previous Message Christian Ullrich 2012-08-27 21:30:33 Bug in pg_env.bat from one-click installer