Re: Statement timeout in pg_rewind
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: David Fetter <david@fetter.org>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Alexander Kukushkin <cyberdemn@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2019-08-26T04:27:54Z
Lists: pgsql-hackers
On Sun, Aug 25, 2019 at 10:34:29PM +0200, David Fetter wrote: > I meant to ask whether, in addition to pg_dump and pg_rewind, there > are other things that should ignore statement_timeout settings. Sure. Please note that I am not sure if it is worth bothering about all the code paths which emit SQL queries as one thing to consider is that your query "SET statement_timeout = 0" could be cancelled by the system's default, defeating its purpose. (For example, just enforce statement_timeout = 1 into PostgresNode.pm::init and enjoy the show). So any tool that we consider worth fixing should be able to act with timeout values that are realistic. On top of pg_rewind, there is a point to raise about src/bin/scripts/ (just enforce the parameters in common.c), and vacuumlo which creates a temporary table potentially large. Alexander, it seems to me that we should also consider lock_timeout and idle_in_transaction_session_timeout (new as of 9.6), no? We could also group the PQexec/PQresultStatus into a simple wrapper which gets also called by run_simple_query(). -- Michael
Commits
-
Disable timeouts when running pg_rewind with online source cluster
- e9dcbc9c3fb6 9.5.20 landed
- d64789e97cf6 9.6.16 landed
- 19bfa15a8274 10.11 landed
- f51006ea9657 11.6 landed
- e96f524433db 12.0 landed
- be182e4f9e89 13.0 landed