Re: changing the /tmp/ lock file?

Поиск
Список
Период
Сортировка
Искать
От
Ben
Тема
Re: changing the /tmp/ lock file?
Дата
Msg-id
Pine.LNX.4.64.0706131133070.27105@localhost.localdomain
Ответ на
Список
Дерево обсуждения
changing the /tmp/ lock file? Ben <bench@silentmedia.com>
Re: changing the /tmp/ lock file? Tom Lane <tgl@sss.pgh.pa.us>
Re: changing the /tmp/ lock file? Ben <bench@silentmedia.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>
Re: changing the /tmp/ lock file? Ben <bench@silentmedia.com>
Re: changing the /tmp/ lock file? Martijn van Oosterhout <kleptog@svana.org>
Re: changing the /tmp/ lock file? Greg Smith <gsmith@gregsmith.com>
Re: changing the /tmp/ lock file? Greg Smith <gsmith@gregsmith.com>
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  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 по дате отправления
От: Frank Wittig
Дата:
От: Karen Springer
Дата:
Сообщение: recursive function
FAQ