From: | Rob Sargent <robjsargent(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "pgsql-generallists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | Re: tcp settings |
Date: | 2022-09-21 15:44:56 |
Message-ID: | 9D6C46C0-8840-4775-9E94-B2755E50CB16@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> On Sep 20, 2022, at 10:03 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Rob Sargent <robjsargent(at)gmail(dot)com> writes:
>>> then keepalives aren't necessarily the solution anyway. When is
>>> this failure occurring ... is it while trying to establish the
>>> database connection in the first place? Or does it only happen
>>> if you've left the psql session sit idle for a long while?
>
>> Sitting idle for not even a long while. Under half hour I feel would do it. But I don’t think it times out while I’m “SQLing”
>
> OK, that does sound like something that reducing the keepalive
> interval could help with. The traditional keepalive timeout
> is a couple of hours, at least on my Linux box:
>
> $ cat /proc/sys/net/ipv4/tcp_keepalive_time
> 7200
>
> but it sounds like there's something between you and the database
> server that will forget connections a lot quicker than that.
>
> regards, tom lane
I was afraid you would conclude that. But its just plain ol’ psql (inside emacs) on interactive node directly to db server node, all in a “protected environment”. There could be network pieces in the middle that are getting uppity. I’ll ask /them/.
Thanks
From | Date | Subject | |
---|---|---|---|
Next Message | JITEN KUMAR SHAH | 2022-09-21 15:55:49 | Re: 10.22 Windows binaries download? (zip "invalid" on Enterprisedb) |
Previous Message | Rob Sargent | 2022-09-21 15:39:11 | Re: [EXT] pg_stat_activity.backend_xmin |