Re: Long running query causing XID limit breach - Mailing list pgsql-general

From sud
Subject Re: Long running query causing XID limit breach
Date
Msg-id CAD=mzVVhE4Y637XOkqK1yMzP6U2aRhBi5xTcEZw6_Ppppb6mqA@mail.gmail.com
Whole thread Raw
In response to Re: Long running query causing XID limit breach  (Simon Elbaz <elbazsimon9@gmail.com>)
Responses Re: Long running query causing XID limit breach
List pgsql-general
On Wed, 5 Jun, 2024, 12:39 pm Simon Elbaz, <elbazsimon9@gmail.com> wrote:
Hi,

I am following this very interesting thread.

From the documentation https://www.postgresql.org/docs/current/runtime-config-client.html#GUC-IDLE-IN-TRANSACTION-SESSION-TIMEOUT, the 0 value will disable the timeout (not -1).



On Wed, Jun 5, 2024 at 8:25 AM sud <suds1434@gmail.com> wrote:
Hello Laurenz,

Thank you so much.This information was really helpful for us understanding the working of these parameters.

One follow up question i have , as we are setting one of the standby/replica with value idle_in_transaction_session_timeout=-1 which can cause the WAL's to be heavily backlogged in a scenario where we have a query running for very long time on that instance. So in that case will there be chances of instance restart and if that can be avoided anyway?

And the plan is to set these system parameters with different values in writer/read replica , so in that case if we apply the "alter system" command on the primary , won't the WAL going to apply those same commands forcibly on reader instance making those same as the writer instance configuration( but we want the reader replica configuration to be different from writer)? 

Appreciate your guidance.
 

My apologies. I was meant to say setting up "max_standby_streaming_delay" To -1. Which means unlimited lag. 

pgsql-general by date:

Previous
From: Simon Elbaz
Date:
Subject: Re: Long running query causing XID limit breach
Next
From: Radu Radutiu
Date:
Subject: Re: Postgresql 16.3 Out Of Memory