Re: postmaster locking issues - Mailing list pgsql-hackers

From Tom Lane
Subject Re: postmaster locking issues
Date
Msg-id 4634.966919807@sss.pgh.pa.us
Whole thread Raw
In response to postmaster locking issues  ("suchet singh khalsa" <suchet_singh@hotmail.com>)
List pgsql-hackers
"suchet singh khalsa" <suchet_singh@hotmail.com> writes:
>      This issue of the locking abilities of the postmaster has been 
> discussed before (see the reference section below). However, it seems that 
> it was dropped without any action plan, especially the part about point 3 : 
> "Two PID files will be necessary, one to prevent mulitple instances of 
> postmasters from running against the same data base, and one to prevent 
> multiple instances from using the same port."

No, this was fixed long since.  In 7.0 I see the following behavior:

Try to start a postmaster on an already-in-use port number:
FATAL: StreamServerPort: bind() failed: Address already in use        Is another postmaster already running on that
port?       If not, wait a few seconds and retry.postmaster: cannot create INET stream port
 

Try to start a postmaster on a free port in an in-use data directory:
Can't create pid file: /home/postgres/testversion/data/postmaster.pidIs another postmaster (pid: 3124) running?

Proper detection of port conflicts may be platform-dependent ...
what platform are you running on?

Actually, given your stated observation:

>      We are using PostgreSQL 7.0 along with Enhydra 3.0 application server 
> to host a web site. It has been observed that sometimes (can't pinpoint when 
> it starts) the postmaster instance 'hangs' and another starts. Then the new 
> one hangs and another starts. This happens until the max limit for backends 
> is reached (32 in our case). Then the whole application crashes.

I'll bet that what you are seeing is not multiple postmasters at all,
but multiple backends.  Does "Enhydra" open up new database connections
without bothering to close old ones?  If so, that's where the problem
lies.  A backend will normally not quit until it sees a proper
termination message or connection closure from its client.  We've heard
of quite a number of broken apps that do not reliably close
connections...
        regards, tom lane


pgsql-hackers by date:

Previous
From: The Hermit Hacker
Date:
Subject: Re: How Do You Pronounce "PostgreSQL"?
Next
From: sergiy grigoriev
Date:
Subject: postgresql-java (fwd)