From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | David Fetter <david(at)fetter(dot)org> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alexander Kukushkin <cyberdemn(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Statement timeout in pg_rewind |
Date: | 2019-08-26 04:27:54 |
Message-ID: | 20190826042754.GB7005@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2019-08-26 04:45:13 | Re: pg_upgrade: Error out on too many command-line arguments |
Previous Message | Gareth Palmer | 2019-08-26 04:14:11 | Re: [PATCH] Implement INSERT SET syntax |