public inbox for [email protected]
help / color / mirror / Atom feedNon-robust plpgsql_trap test
2+ messages / 2 participants
[nested] [flat]
* Non-robust plpgsql_trap test
@ 2026-04-21 13:54 Tom Lane <[email protected]>
2026-04-21 14:20 ` Re: Non-robust plpgsql_trap test Andrew Dunstan <[email protected]>
0 siblings, 1 reply; 2+ messages in thread
From: Tom Lane @ 2026-04-21 13:54 UTC (permalink / raw)
To: [email protected]
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
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: Non-robust plpgsql_trap test
2026-04-21 13:54 Non-robust plpgsql_trap test Tom Lane <[email protected]>
@ 2026-04-21 14:20 ` Andrew Dunstan <[email protected]>
0 siblings, 0 replies; 2+ messages in thread
From: Andrew Dunstan @ 2026-04-21 14:20 UTC (permalink / raw)
To: Tom Lane <[email protected]>; [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
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2026-04-21 14:20 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-04-21 13:54 Non-robust plpgsql_trap test Tom Lane <[email protected]>
2026-04-21 14:20 ` Andrew Dunstan <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox