Ok, I let the server run for a few days (usually long enough to get into
this situation) and then did a shutdown. No hang. Could be fixed.
Thanks!
L.
On Mon, 17 Feb 2003, Tom Lane wrote:
I said:
Oh, duh! You don't need to be using NOTIFY explicitly --- you just have
to sit idle long
On Monday February 17 2003 8:06, Tom Lane wrote:
Attached is the fix against 7.3 (or CVS tip). The same bug exists
in 7.2 and 7.1, and should be fixable by the same patch (possibly
with some fuzz).
You can demonstrate the problem by doing 'LISTEN foo' in one psql
and then 'NOTIFY foo' in
Laurette Cisneros [EMAIL PROTECTED] writes:
Ok, my production server had this problem (again). So, here's the info.
you requested. There's a lot of postgres processes still left running:
postmaster (proc id 1457):
(gdb) print Shutdown
$1 = 2
Okay, so the postmaster definitely got the
Ed L. [EMAIL PROTECTED] writes:
I've been seeing the same problem intermittently over the past 2 years
among ~30 production clusters.
Hm, I suddenly have a theory. Do you guys use LISTEN/NOTIFY in the
databases that are exhibiting the problem? Is it possible that the
backends that aren't
Ok, my production server had this problem (again). So, here's the info.
you requested. There's a lot of postgres processes still left running:
postmaster (proc id 1457):
(gdb) print Shutdown
$1 = 2
Other backends (postgres) still hanging around:
postgres 1458 1457 0 Feb06 ?00:22:41
Ed L. [EMAIL PROTECTED] writes:
On Monday February 17 2003 5:09, Tom Lane wrote:
Hm, I suddenly have a theory. Do you guys use LISTEN/NOTIFY in the
databases that are exhibiting the problem?
Not using LISTEN/NOTIFY here, at least not of which I'm aware. I'll
dig a little more and let you
I said:
Oh, duh! You don't need to be using NOTIFY explicitly --- you just have
to sit idle long enough to make the SI buffer overflow, and the system
will try to NOTIFY your backend anyway to make it read the SI message
buffer. Which is the path I was looking at --- that will leave
Ok, it reproduced today on my development server.
Here's the info:
/usr/local/pgsql/bin/pg_ctl -D /u1/pgsql73_data -m fast -l
/u1/pgsql73_data/pgsql.log stop
waiting for postmaster to shut
down failed
pg_ctl: postmaster does
Laurette Cisneros [EMAIL PROTECTED] writes:
Ok, it reproduced today on my development server.
Boy, it sure looks like everything's just sitting idle waiting for
client input, and hasn't noticed your shutdown request at all. You
sure you used -m fast? Could you attach to the postmaster and see
Sure, next time it happens. I'm back up again.
On Thu, 13 Feb 2003, Tom Lane wrote:
Laurette Cisneros [EMAIL PROTECTED] writes:
Ok, it reproduced today on my development server.
Boy, it sure looks like everything's just sitting idle waiting for
client input, and hasn't noticed your
Laurette Cisneros [EMAIL PROTECTED] writes:
When I do a shutdown:
$pgpath/bin/pg_ctl -D $datadir -m fast stop
the server will not completely shutdown.
Hm. -m fast tells the postmaster to send SIGTERM to all the existing
backends, and then quit when all the backends have quit. So your
Sure.
I will attempt this on our development server which only occasionally has
this problem. If that won't reproduce it, I will attempt this on our
production server but that must be scheduled at a slow time - maybe Monday.
I'll send this info. once I've collected it.
Thanks for the help,
L.
Server won't shutdown:
Currently, we are running 7.3.2. However, we have had this problem since 7.1.
Our production server has dozens of connections from different persistent
applications (some web, some runnning on other systems).
When I do a shutdown:
$pgpath/bin/pg_ctl -D $datadir -m fast
13 matches
Mail list logo
