Re: BUG #15196: bogus data in lock file "postmaster.pid"

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: dmigowski(at)gmail(dot)com
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #15196: bogus data in lock file "postmaster.pid"
Date: 2018-05-14 16:02:57
Message-ID: 21836.1526313777@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

=?utf-8?q?PG_Bug_reporting_form?= <noreply(at)postgresql(dot)org> writes:
> my system crashed and after a reboot PostgreSQL would not come up again.
> After some while I found out that there was information in the System event
> logs and it was immediately clear that I had to remove the stale log file.
> On my Linux production systems it is not that bad, because Systemd kills the
> pid files on reboots, but I somehow feel like on Windows the database
> shouldn't be that bad.

TBH, my opinion about that is "don't use Windows for production"; but
especially not an installation you haven't vetted for plug-pull safety.
A database can't be any more robust than the platform it sits on top of.

(That goes just as much for non-Windows of course. If you haven't
verified fsync safety of a Unix-ish system, it probably isn't safe.)

> Why don't you implement one of the tons of other possibilites to log the
> current installation on a windows system?

I have no particular desire to do this differently on Windows than
elsewhere, especially since there's exactly zero evidence that doing
it differently would improve anything. Filesystem corruption after
a crash can affect lots of things.

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message David G. Johnston 2018-05-14 16:09:26 Re: Abnormal JSON query performance
Previous Message Tom Lane 2018-05-14 15:53:34 Re: Abnormal JSON query performance