On Sat, 4 May 2002, Tom Lane wrote: > Matthew Kirkwood <[EMAIL PROTECTED]> 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.
How about a second, data directory based socket simply named something like '.inuse', that is not port dependent? ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org
