Re: changing the /tmp/ lock file? - Mailing list pgsql-general

From Ben
Subject Re: changing the /tmp/ lock file?
Date
Msg-id Pine.LNX.4.64.0706131133070.27105@localhost.localdomain
Whole thread Raw
In response to Re: changing the /tmp/ lock file?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: changing the /tmp/ lock file?  (Greg Smith <gsmith@gregsmith.com>)
Re: changing the /tmp/ lock file?  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: changing the /tmp/ lock file?  ("Robin Ericsson" <lobbin@gmail.com>)
List pgsql-general
Why would that be a problem if each is configured to listen on different
addresses?

But maybe a better question to ask would be how people are doing failover
in the case where you have two servers, each handling a seperate set of
data and acting as backup for each other. I fully expect things to go
slower during failover periods, but in my case, that's better than
doubling my hardware.

On Wed, 13 Jun 2007, Tom Lane wrote:

> Ben <bench@silentmedia.com> writes:
>> I'm trying to impliment an automatic failover system, and am running into
>> the problem that when I try to start multiple postgres clusters on the
>> same box, postgres will not start if /tmp/.s.PGSQL.5432.lock exists. Can I
>> change the file it's looking for via an option? Nothing seemed obvious
>> from a quick review of the docs, short of (presumably) changing the port
>> number, which I don't want to do.
>
> That lock file exists specifically to keep you from doing that (ie,
> having more than one postmaster listening on the same port).  Trying
> to defeat the lock is not a good idea.
>
>             regards, tom lane
>

pgsql-general by date:

Previous
From: Frank Wittig
Date:
Subject: Re: pg_xlog - files are guaranteed to be sequentialy named?
Next
From: Karen Springer
Date:
Subject: recursive function