Thank you @Merlin Moncure <[email protected]> , @Greg, @Christophe, @Justin <[email protected]> ,
We've been using pgCat for the last 18 months and it's stable and serves 22 million requests daily. This is the first time, we've observed such behaviour; therefore, we quickly reported the case here, and see whether I'm missing anything.. I am unable to reproduce the issue again with both pgCat and PostgreSQL; it seems to have happened only once. I will report the case to the pgCat team as well, and will update the thread with their input. Thank you so much again for the prompt response. On Tue, Sep 8, 2026 at 9:53 PM Merlin Moncure <[email protected]> wrote: > On Sat, Sep 5, 2026 at 7:30 AM Greg Sabino Mullane <[email protected]> > wrote: > >> This is not a normal FATAL from the server - that particular message is >> coming from pgcat, not from Postgres. So the normal FATAL/connection >> terminated/reconnect flow is not relevant here, as it is pgcat that is >> responsible for all this. The FATAL is being sent to the client only - >> pgcat is probably releasing that connection and fetching you a new one in >> the background. Try tweaking your idle_client_in_transaction_timeout >> setting in your pgcat config to duplicate/debug the behavior, and sprinkle >> some pg_backend_pid() calls in there. >> > > 100% this. It looks like pgcat may be mixing up the sessions so that a > transaction might not be 'pinned' properly to a single client after being > opened. I can't say for sure since I'm not so familiar with pgcat but this > looks dangerous; somehow an open transaction may have been checked back > into the pool. > > merlin > -- Regards, Dinesh manojadinesh.blogspot.com
