"Joel Burton" [EMAIL PROTECTED] writes:
On 25 Nov 2000, at 17:35, Tom Lane wrote:
Ugh. The reason that removing the socket file allowed a second
postmaster to start up is that we use an advisory lock on the socket
file as the interlock that prevents two PMs on the same port number.
Remove
Ah, I see why the data-directory interlock file wasn't helping: it
wasn't checked until *after* shared memory was set up (read clobbered
:-(). This was not a very bright choice. I'm still surprised that
the shared-memory reset should've trashed your database so thoroughly,
though.
Over
"Joel Burton" [EMAIL PROTECTED] writes:
I think it wasn't just two views pointing at each other (it would, of
course, be next to impossible to even create those, unless you hand
tweaked the system tables), but I think was a view-relies-on-a-
function-relies-on-a-view kind of problem.
Oh,
On Sat, Nov 25, 2000 at 07:41:52PM -0500, Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Actually, this turns out to be similar to what you wrote in
http://www.postgresql.org/mhonarc/pgsql-hackers/1998-08/msg00835.html
Well, we've talked before about moving the socket files to
* Tom Lane [EMAIL PROTECTED] [001125 16:37]:
"Joel Burton" [EMAIL PROTECTED] writes:
This story does indicate that we need a less fragile interlock against
starting two postmasters on one database. I have to admit that it
hadn't occurred to me that you could break the port-number interlock
Tom Lane writes:
There is a related issue on my todo list, though --- didn't we find out
awhile back that some older Linux kernels crash and burn if one attempts
to get an advisory lock on a socket file? (See thread 7/6/00) Were we
going to fix that, and if so how? Or will we just tell
Peter Eisentraut [EMAIL PROTECTED] writes:
Maybe we could name the socket file .s.PGSQL.port.pid and make
.s.PGSQL.port a symlink. Then you can find out whether the postmaster
that created the file is still running.
Or just create a lockfile /tmp/.s.PGSQL.port#.lock, ie, same name as
socket
