"Joel Burton" <jburton@scw.org> 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 the socket file, poof no interlock.
>>
>> *However*, there is a second line of defense to prevent two
>> postmasters in the same directory, and I don't understand why that
>> didn't trigger. Unless you are running a version old enough to not
>> have it. What PG version is this, anyway?
> 7.1devel, from about 1 week ago.
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 the past two days I've committed changes that should make the data
directory, socket file, and shared memory interlocks considerably more
robust. In particular, mechanically doing "rm -f /tmp/.s.PGSQL.5432"
should never be necessary anymore.
Sorry about your trouble...
BTW, your original message mentioned something about a recursive view
definition that wasn't being recognized as such. Could you provide
details on that?
regards, tom lane
