From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
Cc: | Teja Jakkidi <teja(dot)jakkidi05(at)gmail(dot)com>, pgsql-admin <pgsql-admin(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Statement_timeout in procedure block |
Date: | 2024-06-19 14:58:33 |
Message-ID: | 114105.1718809113@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> writes:
> What works is setting the parameter on the procedure:
> test=> CREATE OR REPLACE PROCEDURE sit() LANGUAGE plpgsql SET statement_timeout = 2000 AS 'BEGIN PERFORM pg_sleep(5); END;';
> CREATE PROCEDURE
That doesn't work either, for me, and I would not expect any of these
variants to do so. The reason is that statement_timeout is defined
to limit the runtime of a "statement" defined as a single command
received from the client --- in this case, the CALL statement --- and
the timer starts running (or doesn't) at the time of command receipt.
So it's the previously-prevailing value of statement_timeout that
determines what happens, and no amount of thrashing within the command
will change the already-established overall timeout for it.
If you're desperate, transaction_timeout might serve for this, since
it looks like changes in that affect the timer immediately. But
it has the effect of killing the session altogether, which is
probably a bigger hammer than you want.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Laurenz Albe | 2024-06-19 15:06:41 | Re: Statement_timeout in procedure block |
Previous Message | Michael Banck | 2024-06-19 08:12:04 | Re: Urgent: Segmentation Fault in PostgreSQL postmaster Process |