public inbox for [email protected]  

help / color / mirror / Atom feed

From: Tom Lane <[email protected]>
To: [email protected]
Subject: Non-robust plpgsql_trap test
Date: Tue, 21 Apr 2026 09:54:54 -0400
Message-ID: <[email protected]> (raw)

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

view thread (2+ messages)  latest in thread

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]
  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