Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sCEMR-0045Gm-Vc for pgsql-general@arkaria.postgresql.org; Wed, 29 May 2024 08:08:41 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1sCEMR-00E1jZ-5s for pgsql-general@arkaria.postgresql.org; Wed, 29 May 2024 08:08:39 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sCEMQ-00E1jF-Mf for pgsql-general@lists.postgresql.org; Wed, 29 May 2024 08:08:38 +0000 Received: from mail-ed1-x531.google.com ([2a00:1450:4864:20::531]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sCEMK-002USr-3t for pgsql-general@lists.postgresql.org; Wed, 29 May 2024 08:08:37 +0000 Received: by mail-ed1-x531.google.com with SMTP id 4fb4d7f45d1cf-578626375ffso1962991a12.3 for ; Wed, 29 May 2024 01:08:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybertec-at.20230601.gappssmtp.com; s=20230601; t=1716970110; x=1717574910; darn=lists.postgresql.org; h=mime-version:user-agent:content-transfer-encoding:autocrypt :references:in-reply-to:date:cc:to:from:subject:message-id:from:to :cc:subject:date:message-id:reply-to; bh=NLzlbjkijnoS8kbMa+wW3I35QVFRNxnp0CO1ev9H7lw=; b=pfTeT+PsYHBlmk7/cOOy3A/5YyzfxNbWIyGRAwDqjJ9ZDxzTxMrs3qM/qcgGzOJ26S IpIgbARLBCRTlFBUlLhwblGvh3C1pVby50Lc7NJdYFv8sfJO8650bir7OSIttWY8Dl+i RTP9IuoTVIztlc4ERSQP9OIbkCSQG0ysQTyMF6MQlmliYntv5JWn0+UmY6Bm+zOWiSrL QxfjDd7ThfWnR/TDrSHsiyOkuzWe1eOf0tbCWWmcxCAYVivL2gYwt/NNlYrzUnE1qgP5 1Bfb60K7bULFjdzyO5QGlC/i90BAAyAgJYIWcF9nD26R3HPVkyk/Ch/OdNkqGu6PSxN7 624g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716970110; x=1717574910; h=mime-version:user-agent:content-transfer-encoding:autocrypt :references:in-reply-to:date:cc:to:from:subject:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=NLzlbjkijnoS8kbMa+wW3I35QVFRNxnp0CO1ev9H7lw=; b=BOJCALBjZPvZ0Z1j14a4q8mGDURgglsTmpRZCjQ3vy2SKd6Rr/N0t2gnZtRYTKpW+6 lhGMkvWKVYHoZT2ywYF3pTeZZX4430vel+poFIoL2NbTsW2Kh2L3GZkrzdc/7XFP/2P7 URLrZfFGgCzo1INGoiecAJXQGVIw3hXBNKdytc2SMNtoYSoK3yFx8rakmTbTE5TOBhK4 T3Erk5ww2JHWjCYRihg4H8iPfuGN7oRQulhl7DG8XgePeHDzd5tUNGyVjDmJA2kTfg9y xgqPnoA5gWeJ+y3S5W+zYalfgdr0JoC5gXRDQO/h5N1pwKhK4SzwPnX3ZZZ+clAD050L fXjw== X-Forwarded-Encrypted: i=1; AJvYcCWrVaBVkXjBhFAXAku2CzjgDjfWpPw+2J0k4J0f2I9TjKI8itbDRAzZw+AQOIgBEx1AP1Nx1P67IfoXQouDOG4pF3l3mkKBDaw8LP2JUc7iQQmE X-Gm-Message-State: AOJu0Yx12QUGFDNHhNT+HG8NqIMf+94UOC3D7M4usGS/TBgfWUG0q3Hi 2uXCGc2mz+oSuEDEZTGh4nQbK/xoM0F/Q2qpwu46dfAp44t7BzO7YlM1bNv5JnE= X-Google-Smtp-Source: AGHT+IGehXbRK1h+4bBF+oGML+xL+t1NwNOquwkQacDd30l3PgxNqsTauuJrnF/ynJIKKot1LS9B0g== X-Received: by 2002:a50:9f81:0:b0:578:f472:d9d5 with SMTP id 4fb4d7f45d1cf-578f472dba5mr6395436a12.37.1716970110232; Wed, 29 May 2024 01:08:30 -0700 (PDT) Received: from localhost.localdomain ([2001:871:5e:ed19:7736:9a80:1156:2d8c]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5786450bb13sm6409333a12.72.2024.05.29.01.08.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 May 2024 01:08:29 -0700 (PDT) Message-ID: <56ad97911d83f721dd872e8ee68cd77d50d3eef6.camel@cybertec.at> Subject: Re: Long running query causing XID limit breach From: Laurenz Albe To: yudhi s Cc: sud , pgsql-general Date: Wed, 29 May 2024 10:08:29 +0200 In-Reply-To: References: <891bcfec74f7358ef0212caf6565a35153dd2941.camel@cybertec.at> Autocrypt: addr=laurenz.albe@cybertec.at; prefer-encrypt=mutual; keydata=mQINBGGDwAQBEADgbWy5cKXQld3N2mF+DFyiNFbi2oBl2T+XgxpPF8wTRw2D/u4bBKXP0SYSE/lA86jIVNWWU0gf1KODIkVvgJm2w4vH2VBV1b7ddVViGl1Iu+9zaRnv9wulhnH42KefepXnoean6UT1EzLM0opF/Ik0j+40TxdRtobkBprkQUyHDXWlHc2ffPs3SipyFEP9AVLf7ejRC46CXWDnsqjOBSMEW8Z4HiK/8RrPZBsKLts8dJxKF4pygOdJb0CWk8k/X1jbcfdxo+zOLjOMvJcSJ2pFdJmQHU+JufB3rePziqQ2S9Ur6sccr9XnTC1GVBWN4Lf5VHq+vf+bFJjVwg+2hrySZnAVfcOrxoqFLErr7ug1zN2nM1kcpgA4VWn4gxlJtYNYYq+9WxX5dtvnNANlG3ZCrRKQzl8lxtzoF6Zo7LUhEqPaHDwn7Rvs+IdbOn41lF5UDTJGqmC4gS/bZydW2Fy3YWm4aSaN9fgFf8D+PVkrlKAZB7gBLz1TyHjbcRf85cYF+GKKrDld5SzMB/V60VX3oP/Eo8ikFpyWaqiz1f9X7MBot3/PjJkY+wDzp3nmb19QEcOBuQiSQ4xds2r0HewbuHTAR68u8jNNMGmpm2j4x+g09Jd/WQDjqlTBZ/jEltH41fYCCPWMfljXTOOXu2eLNGdfi7ETZogtwjM9oTtSPQARAQABtCdMYXVyZW56IEFsYmUgPGxhdXJlbnouYWxiZUBjeWJlcnRlYy5hdD6JAk4EEwEIADgWIQR0CqhbZGGABqoaSbdi8bhXA2EdmAUCYYPABAIbAwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRBi8bhXA2EdmM/6EADK232JCwmBzhlj8h7U9CjG6kx0JHP3uJGv+XfsHtHAlmY/RCwF1BHMEsRlk bT5UrLvJ2jb99bA9QARzhFaxzyn0F/BUKzuIjRGNs/n6d5dNUFA0kOt8sX+TacmC GEyjEBCrVCm4ranBiUyePn9NhHNWnaex7pJyqvMLLdwW9BEMJx0Fqo+DN8ukbXmYRsmhEtd3ue+x/luYmOmJnaGtzInaY5aOJYbW9XqoRIZkZvOCgbi1FfvNmoqWa+3oVxTOgw9RafjJDyW0lTHzKGjbGI5ofMU98l+/hKJFYJqWUF6VpFJY5YIcN/1lf4ZICMwDl+MPIVo/tpq8L10seJL28nLlvw3K+cI+TVW8IW/qL/LyVoDofI3USeOORuYmhpWRhik8JXX6xf3v6GrRilJIPWNFIJbxm1ZblQiQnOw3IOW7T+8nAmPin1HKqM3VrOrJQ2VtShsefNBibNAsr1oFaqcDBkn3yGG8i6CTW+FyO4PZ+/EwNxMVgktxbYdy5AT1/lpXr5tB+phhLIyVfiBvrWs5EThxYMQ/L8Y85c3GMsAy1l/x4h3jqySIYy3SCU9+jc5UVuNnXljbvkEzJ+NLWJ6C1rACFWrMszgPdh5tCrlRY9PpmYll4JbCgb8BtxEIUmR+xr50/ZElEK5iml7Q00KUekCcDt+36PsyGFTXBzNOrkCDQRhg8AEARAAzOZ2tLHlI4rrhG411h6cdCFjBZxuljaFCxFyHn3m6wbGLqwBUWC5k8UrRqjHMz88KcTSaNO7XGAmCqPdWd2SeflPZRnNTbjsVpw7mLdffsBm4JX7kki2Pvk5h0NtYeidXT1PSpc2ri4DutYXuT9uD8RAm1wUDCE5HQNUihT/WH6opt+hskHW21uHao0+y822tG0QQcGMqdQR5Vxdxj89wiEPdqW+HpU/oOZIhrf2E7prduAppxixjHy/o1rcnoznnJvc8D3+YgI9O0LrBMij89dM55pRGbLovTR1oGR3U74sX774+0xmSzeIKwZfiMUz7Atlvfk5SHOsRUFPN2Ux9kaXiiBibQpHFxt7b lDrT4wxdLJ/XCdbPPAyl+lZtOLsaHEEZvYNyTXwZc35dVf3R4/oz20HoG6s7ct8e1 AQygj43XAERzty9SkWgxs8+grp1PrGx6FHVSYRqBM8dS/ZR6yRVwOwJXPyaSSqfIF21DkE4j1y4n+ItSewPGoRp8K/yWCikt6qlkVkO2ASNIiX04fAbtzwVOaNn8ZMRNqyvLc1fED4sr49onE4cAIcBLjcC3KL+w9DUGRQCdziROj5H2Yl/sXGPdMciUHo/Uz2rggc+2th3bQiMhrHWSsBpUkDQp0yWewemstPpPgBL3h2fHKaX8B9oH5Qu/H1IgrOuX8AEQEAAYkCNgQYAQgAIBYhBHQKqFtkYYAGqhpJt2LxuFcDYR2YBQJhg8AEAhsMAAoJEGLxuFcDYR2YuPwQAMkpGtR80pQ1gVsONhdkqj0H2eU66efP/gO3CoyaoIcvrpKYj7C2HipVSmkt1gpByL0X4AMQ/vKuknUz3wd28Ba+G1dCfbVs/Xiusq+SmpUj5rTwmYqdSjWMuCo1R6oS5hdJMdUUJYGMT0QkVlm1KnW8jkmCTl9GzjDxOAsN9O6/6lPzaGFtk9XF+34Bry/N4HKiJkqpC4+UTd0AprPfzJ2jdT64e1F0+W88X8y1bTTgNrHwK4mDiLnlE4SKRuEm54lNhJz//ar86Or5BErzNpM6TL7lk44QS06hwsMrEdKIy8J/SYJPjfzR8tIUnKscclVpOgjKaBqC+0iFiVaRqAgfOlIEiezX6kMh5Q2FIUfqs46qWhhXjRrdKOEoStYAaikdLu5ZXr7vfb0ZaDh+ZwTQtbSMFolyOkecwI81MCdbMfT/1TqIGTOdAj5as9fAakk0jb2pXgUYQ8X1DVTR8ahSDVEaw9VTmWiSvTxvguVJ1Mb7gG4Gmh6aviDTJhfXtH4rPUNXhDLqrTH8JkJjyKROOMakIF68Hjse5vUfUxreBEOtb5r1Coa2Fe7ncJayaSE7ryrDbFqpZ 36UMAx4ulWMyqJajLNGY0DdG8qIsR5nxRhrnK/mrCidZ8F9/D3bWAl4rjtHlsztN59 +AnW5l0HsQcY9ntFL/zEBOaonjdJf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.50.4 (3.50.4-1.fc39) MIME-Version: 1.0 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Wed, 2024-05-29 at 01:34 +0530, yudhi s wrote: > > The only way you can have no delay in replication AND no canceled queri= es is > > if you use two different standby servers with different settings for > > "max_standby_streaming_delay".=C2=A0 One of the server is for HA, the o= ther for > > your long-running queries. > > When you suggest having different max_standby_streaming_delay for first r= eplica > (say 10 sec for High availability) and second replica(say -1 for long run= ning queries). > Do you also suggest=C2=A0 keeping "hot_feedback_standby" as "OFF" for all= the three > instances i.e. master and both the replicas? The parameter is ignored on the master. It needs to be off on the standby that is running long queries. For the other standby it probably doesn't matter if you are not running any queries on it. I would leave "hot_standby_feedback =3D off" there as well. Actually, I would set "hot_standby =3D off" on the standby that is only use= d for HA. > Also OP has added a few other parameters as below, do you think these sho= uld be needed?=C2=A0 > =C2=A0I think the master and first replica should have the same set up be= cause in=C2=A0case > of any disaster to master the first replica should be able to take the pl= ace of master. > =C2=A0 > Master/Primary First Replica/Standby for High Availability Second Repl= ica for Reporting > hot_standby_feedback=3DON hot_standby_feedback=3DON hot_standby_feed= back=3DOFF > max_standby_streaming_delay=3D10 sec max_standby_streaming_delay=3D10 se= c max_standby_streaming_delay=3D-1 (Infinite) > statement_timeout =3D "2hrs" statement_timeout=3D"2hrs" No statement_= timeout i.e. infinite > idle_in_transaction_session_timeout=3D10minutes idle_in_transaction_sessi= on_timeout=3D10minutes No idle_in_transaction_session_timeout i.e. infinite > autovacuum_freeze_max_age=3D100M autovacuum_freeze_max_age=3D100M auto= vacuum_freeze_max_age=3D100M > Log_autovacuum_min_duration=3D0 Log_autovacuum_min_duration=3D0 Log_a= utovacuum_min_duration=3D0 - I would leave "hot_standby_feedback" off everywhere. - "max_standby_streaming_delay" should be -1 on the reporting standby and v= ery low or 0 on the HA standby. It doesn't matter on the primary. - "statement_timeout" should be way lower on the first two nodes. - "idle_in_transaction_session_timeout" is good. - I would leave "autovacuum_freeze_max_age" at the default setting but 100 = million is ok too. Yours, Laurenz Albe