On Sun, January 13, 2008 6:53 pm, henry wrote:
On Sun, January 13, 2008 7:25 pm, Tom Lane wrote:
Martijn van Oosterhout [EMAIL PROTECTED] writes:
On Sun, Jan 13, 2008 at 08:40:34AM +0200, henry wrote:
lsof doesn't tell me what's talking to PG through /tmp/.s.PGSQL.5432
either. Maybe I'm not
henry [EMAIL PROTECTED] writes:
WRT the origional question: why is tcp_keepalives_idle being ignored
(whether with SET or in postgresql.conf)? - ie, SHOW ALL says it's 0 no
matter what I do.
I think you're looking at it in a session that's connecting over a Unix
socket. You need to be
henry [EMAIL PROTECTED] writes:
The culprit in my case was a local trigger firing on INSERTs using
dblink_exec() without 'host=127.0.0.1'. Bad news though, even _with_
'host=127.0.0.1' the connections do not idle timeout. They just hang
around waiting for the rapture.
So,... this appears
On Mon, January 14, 2008 5:46 pm, Tom Lane wrote:
So,... this appears to be dblink related after all. I'll be trying
explicit open/exec/close. Weird that dblink_exec in a trigger doesn't
release resources.
Hmm, this is the transient-connection form of dblink? If so, that would
be a bug.
On Mon, January 14, 2008 12:49 pm, henry wrote:
WRT the origional question: why is tcp_keepalives_idle being ignored
(whether with SET or in postgresql.conf)? - ie, SHOW ALL says it's 0 no
matter what I do.
A quick follow-on with more info to my own post.
The culprit in my case was a local
On Sat, January 12, 2008 6:50 pm, Tom Lane wrote:
henry [EMAIL PROTECTED] writes:
I have tried setting tcp_keepalives_idle = 120 (eg), then restarting PG,
but SHOW ALL; shows tcp_keepalives_idle=0 (ignoring my setting).
Just FYI, this is the expected behavior on platforms where the kernel
On Sun, Jan 13, 2008 at 08:40:34AM +0200, henry wrote:
This is all irrelevant to your real problem, to judge by the rest of
the thread, but I'm curious.
I did in fact find a leak in long-lived procs (some of which can run for
days) - but squashing that did not make my problem go away. In
Martijn van Oosterhout [EMAIL PROTECTED] writes:
On Sun, Jan 13, 2008 at 08:40:34AM +0200, henry wrote:
lsof doesn't tell me what's talking to PG through /tmp/.s.PGSQL.5432
either. Maybe I'm not understanding exactly how /tmp/.s.PGSQL.5432 is
used - what would connect to PG via a domain
On Sun, January 13, 2008 7:25 pm, Tom Lane wrote:
Martijn van Oosterhout [EMAIL PROTECTED] writes:
On Sun, Jan 13, 2008 at 08:40:34AM +0200, henry wrote:
lsof doesn't tell me what's talking to PG through /tmp/.s.PGSQL.5432
either. Maybe I'm not understanding exactly how /tmp/.s.PGSQL.5432
Hello all,
PG: 8.2.4
We have a very busy setup using multiple clusters, slony, etc. My problem
relates to the number of postgres procs increasing, and not decreasing
when idle. I eventually end up with thousands of idle processes listening
on /tmp/.s.PGSQL.5432 and not quitting (eventually
henry [EMAIL PROTECTED] writes:
tcp_keepalives_interval and tcp_keepalives_count I have left on default.
After a few hours worth of running, theres a few thousand idle postgres
procs, and they're all idle...
Are you sure the clients are actually gone? tcp keepalives are only going to
help if
We have a very busy setup using multiple clusters, slony, etc. My problem
relates to the number of postgres procs increasing, and not decreasing
when idle. I eventually end up with thousands of idle processes listening
on /tmp/.s.PGSQL.5432 and not quitting (eventually bumping into
On Sat, January 12, 2008 1:20 pm, Gregory Stark wrote:
henry [EMAIL PROTECTED] writes:
tcp_keepalives_interval and tcp_keepalives_count I have left on default.
After a few hours worth of running, theres a few thousand idle postgres
procs, and they're all idle...
Are you sure the clients are
henry [EMAIL PROTECTED] writes:
I have tried setting tcp_keepalives_idle = 120 (eg), then restarting PG,
but SHOW ALL; shows tcp_keepalives_idle=0 (ignoring my setting).
Just FYI, this is the expected behavior on platforms where the kernel
doesn't allow adjustment of the TCP keepalive
14 matches
Mail list logo
