Re: bug in SignalSomeChildren
От | Robert Haas |
---|---|
Тема | Re: bug in SignalSomeChildren |
Дата | |
Msg-id | AANLkTikOf9iTWGRqbzmgVJ0yV6hxqy87Pkqa3vKPpS1c@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: bug in SignalSomeChildren (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: bug in SignalSomeChildren
|
Список | pgsql-hackers |
On Mon, Dec 20, 2010 at 2:07 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Mon, Dec 20, 2010 at 1:26 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> Robert Haas <robertmhaas@gmail.com> writes: >>>> Can we add a develop option to force use of the kill(0) method? > >>> How will that avoid needing to have an honest answer from getppid()? >>> Without that you can't know what to issue kill() against. > >> The answer to this question will probably be entirely self-evident if >> you stare at PostmasterIsAlive() for, well, it took me about 10 >> seconds. So probably less than five for you. > > Hmm, I was thinking that PostmasterPid was set originally from getppid, > but it looks like we rely on inheriting it through fork instead. > So maybe this will work. It's still slower and less reliable than the > getppid case for normal use, though. Well, that's why it'd be a developer option, rather than the default behavior. If we can agree on a name I'll work up a patch. Bikeshedding in 3... 2... 1... check_postmaster_via_kill avoid_backend_getppid ...? Another option that might be workable (but I have reservations, and haven't tested it either) is to check whether the return value of getppid() is equal to 1. If it's neither 1 nor PostmasterPid then try kill(). -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: