Magnus,
PostgreSQL 14.6 on x86_64-pc-linux-gnu, compiled by gcc (Debian 10.2.1-6) 10.2.1 20210110, 64-bit
PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
It is docker container if it matters and yep, possibly slow and unreliable network also is an issue.
So you're assuming the statement_timeout parameter should have worked fo that and this is a bug?
Вторник, 26 марта 2024, 17:43 +03:00 от Magnus Hagander <magnus@xxxxxxxxxxxx>:
On Tue, Mar 26, 2024 at 3:19PM Ц <pfunk@xxxxxxx> wrote:Greetings!I’ve faced with strange behavior when I see a lot of active sessions started hours ago while statement_timeout = '30min'.All of them are fetching from cursors.Typical session looks like:backend_start | 2024-03-26 14:34:20.552594+03xact_start | 2024-03-26 14:34:54.974628+03query_start | 2024-03-26 14:35:02.024133+03state_change | 2024-03-26 14:35:02.024134+03wait_event_type | Clientwait_event | ClientWritestate | activebackend_xid | 23240392backend_xmin | 23226474query | fetch all from "<unnamed portal 20>"backend_type | client backendThey are accumulating up to tens by the end of the day with all negative impacts on performance.Initially I thought that clients already died but due to network issues database considers them to be alive. So I set tcp_keepalive GUCs to nonzero values. Without success.Then I checked connections from the app server side and found them in ESTABLISHED state.It's certainly an application fault and it should not hold cursor forever...butIs the any GUC parameters to fight with such «clients»?I wonder if this might be the bug I saw in https://www.postgresql.org/message-id/CABUevExBm_va9+iW0kgVuZbrLDUZ8VnL2wo2ig7jqqdGsy8ZKQ@xxxxxxxxxxxxxx -- basically that there's some path when we're in ClientWrite that it doesn't check for interrupts properly. I've unfortunately not had time to dig into that one anymore.What version of PostgreSQL and what platform are you on?--
