Re: FATAL: bogus data in lock file "postmaster.pid": ""
От | Magnus Hagander |
---|---|
Тема | Re: FATAL: bogus data in lock file "postmaster.pid": "" |
Дата | |
Msg-id | CABUevExKSQ-7Rs2w9uPkuRd9vDEBWRf42YW6JhJndSD_A68EhA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: FATAL: bogus data in lock file "postmaster.pid": "" (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: FATAL: bogus data in lock file "postmaster.pid": ""
|
Список | pgsql-hackers |
On Thu, Jan 5, 2012 at 17:13, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes: >> 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. > > I think link(2) would create race conditions of its own. I'd be > inclined to suggest that maybe we should just special-case a zero length > postmaster.pid file as meaning "okay to proceed". In general, garbage That's pretty much what I meant - but with a warning message. > data in postmaster.pid is something I'm happy to insist on manual > recovery from, but maybe we could safely make an exception for empty > files. +1. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
В списке pgsql-hackers по дате отправления: