Re: Improving backend startup interlock
От | Bruce Momjian |
---|---|
Тема | Re: Improving backend startup interlock |
Дата | |
Msg-id | 200210040109.g9419fq18579@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: Improving backend startup interlock (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Improving backend startup interlock
|
Список | pgsql-hackers |
Have people considered flock (advisory locking) on the postmaster.pid file for backend detection? It has a nonblocking option. Don't most OS's support it? I can't understand why we can't get an easier solution to postmaster detection than shared memory. --------------------------------------------------------------------------- Tom Lane wrote: > Giles Lean <giles@nemeton.com.au> writes: > > I'm certainly no fan of NFS locking, but if someone trusts their NFS > > client and server implementations enough to put their data on, they > > might as well trust it to get a single lock file for startup right > > too. IMHO. Your mileage may vary. > > Well, my local man page for lockf() sez > > The advisory record-locking capabilities of lockf() are implemented > throughout the network by the ``network lock daemon'' (see lockd(1M)). > If the file server crashes and is rebooted, the lock daemon attempts > to recover all locks associated with the crashed server. If a lock > cannot be reclaimed, the process that held the lock is issued a > SIGLOST signal. > > and the lockd man page mentions that not only lockd but statd have to be > running locally *and* at the NFS server. > > This sure sounds like file locking on NFS introduces additional > failure modes above and beyond what we have already. > > Since the entire point of this locking exercise is to improve PG's > robustness, solutions that depend on other daemons not crashing > don't sound like a step forward to me. I'm willing to trust the local > kernel, but I get antsy if I have to trust more than that. > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
В списке pgsql-hackers по дате отправления: