public inbox for [email protected]
help / color / mirror / Atom feedFrom: Andrew Dunstan <[email protected]>
To: Tom Lane <[email protected]>
To: [email protected]
Subject: Re: Non-robust plpgsql_trap test
Date: Tue, 21 Apr 2026 10:20:22 -0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
On 2026-04-21 Tu 9:54 AM, Tom Lane wrote:
> I've noticed a few buildfarm failures similar to [1]:
>
> # diff -U3 /repos/client-code-REL_19_1/HEAD/pgsql.build/src/pl/plpgsql/src/expected/plpgsql_trap.out /repos/client-code-REL_19_1/HEAD/pgsql.build/src/pl/plpgsql/src/results/plpgsql_trap.out
> # --- /repos/client-code-REL_19_1/HEAD/pgsql.build/src/pl/plpgsql/src/expected/plpgsql_trap.out 2026-04-21 04:22:01.030204342 -0300
> # +++ /repos/client-code-REL_19_1/HEAD/pgsql.build/src/pl/plpgsql/src/results/plpgsql_trap.out 2026-04-21 04:29:54.795187855 -0300
> # @@ -155,7 +155,7 @@
> # begin;
> # set statement_timeout to 1000;
> # select trap_timeout();
> # -NOTICE: nyeah nyeah, can't stop me
> # +NOTICE: caught others?
> # ERROR: end of function
> # CONTEXT: PL/pgSQL function trap_timeout() line 15 at RAISE
> # rollback;
> not ok 11 - plpgsql_trap 502 ms
>
> which is coming from unexpected behavior of this bit of plpgsql
> code:
>
> begin
> -- we assume this will take longer than 1 second:
> select count(*) into x from generate_series(1, 1_000_000_000_000);
> exception
> when others then
> raise notice 'caught others?';
> when query_canceled then
> raise notice 'nyeah nyeah, can''t stop me';
> end;
>
> The light bulb went on when I noticed a nearby failure from the same
> machine that was clearly traceable to out-of-disk-space. What
> happened here, I have no doubt, was that the "from generate_series"
> bit tried to make a large temporary file, ran out of space, and threw
> an appropriate error, causing us to take the "wrong" exception
> handler.
>
> Proposal:
>
> 1. Replace that query with something not so resource-intensive.
> I'm not really sure why we didn't just use "perform pg_sleep(10)".
> Maybe it didn't exist or didn't reliably wait 10 seconds at the
> time, but it does now.
>
> 2. Adjust the "when others" handler to report the actual error,
> to make this sort of thing easier to debug next time.
>
> regards, tom lane
>
> [1] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=caiman&dt=2026-04-21%2007%3A21%3A57
Sounds good.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
view thread (2+ messages)
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected]
Subject: Re: Non-robust plpgsql_trap test
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox