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 loc
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
"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 a
"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
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.
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.PG
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 doma
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
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 th
"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 para
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 th
> 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
> max_
"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
h
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 bum
14 matches
Mail list logo
