Re: postmaster locking issues

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "suchet singh khalsa" <suchet_singh(at)hotmail(dot)com>
Cc: hackers(at)postgreSQL(dot)org
Subject: Re: postmaster locking issues
Date: 2000-08-22 04:50:07
Message-ID: 4634.966919807@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"suchet singh khalsa" <suchet_singh(at)hotmail(dot)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.pid
Is 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tatsuo Ishii 2000-08-22 06:35:50 Re: Re: LIKE gripes
Previous Message sergiy grigoriev 2000-08-22 04:03:58 postgresql-java (fwd)