Re: HEADS UP: Win32/OS2/BeOS native ports
От | Tom Lane |
---|---|
Тема | Re: HEADS UP: Win32/OS2/BeOS native ports |
Дата | |
Msg-id | 27984.1020530230@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: HEADS UP: Win32/OS2/BeOS native ports (Matthew Kirkwood <matthew@hairy.beasts.org>) |
Ответы |
Re: HEADS UP: Win32/OS2/BeOS native ports
|
Список | pgsql-hackers |
Matthew Kirkwood <matthew@hairy.beasts.org> writes: > On Fri, 3 May 2002, Tom Lane wrote: >> The SysV API lets us detect that case, but I don't see any >> equally good way to do it if we are using anonymous shared memory. > It's a hack (and has slight security implications), but you > could just allow the postgres backends to keep the listening > socket(s) open. Hmm. That might be workable, but it feels shaky to me. The problem is that you are using a lock based on port number to interlock a data directory --- and port number and data directory are independently variable parameters. Consider$ postmaster -D /my/dir &-- dba thinks "oops, forgot to specify port"$ kill -9 pm-pid # bad idea$ postmaster -D /my/dir -p myport & Any backends started by the first postmaster will not be noticed by the second one, if the interlock is based on port number. We could get around this, of course: record the port number in the data directory lockfile, and test for existence of the old socket independently of trying to create a new one. But it seems ugly. regards, tom lane
В списке pgsql-hackers по дате отправления: