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
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 |