test_aio: Fix broken error recovery assertions in 001_aio

Started by Jelte Fennema-Nio5 days ago3 messageshackers
Beta feature

Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.

won't retrysuccessCI history

This thread has been committed, so CI has stopped here. Anything below is the last result it produced.

You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:

docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t253486
psql -h localhost -U postgres

Built from patchset v1 (message #1), August 20, 2026 at 10:23 AM.

Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:

git clone --branch t253486_1 https://github.com/hackorum-dev/postgres.git

In a checkout you already have, add the fork once:

git remote add hackorum https://github.com/hackorum-dev/postgres.git

then, for this patchset and every later one:

git fetch hackorum t253486_1 && git checkout t253486_1

Patchset v1 (message #1) is on t253486_1

Jump to latest
#1Jelte Fennema-Nio
postgres@jeltef.nl

The three error recovery checks in `test_handle()` used `qr/^|ok$/` to
look for the `ok` marker column in psql's output. That is an alternation
of `^` and `ok$`, and `^` matches every string, so the assertions passed
no matter what psql printed.

Spelling the regex correctly as `qr/^ok\|$/` exposed that the explicit
xact case was actually failing: its marker `SELECT` ran inside the
transaction that the preceding error had already aborted, so it failed
with "current transaction is aborted" instead of showing that an AIO
handle can be acquired again after an error. No statement can succeed in
an aborted transaction, so the recovery statement has to run after the
`ROLLBACK` that ends it, like the subxact case already does after its
`ROLLBACK TO SAVEPOINT`.

The subxact case had no marker column in its query at all, so add one
there, and use the same `SELECT 'ok', handle_get_release()` ordering in
all three checks.

This issue originally found on the pytest framework thread[1]/messages/by-id/DKSSP47Y857Z.1FUU91WMDZWPZ@jeltef.nl.

[1]: /messages/by-id/DKSSP47Y857Z.1FUU91WMDZWPZ@jeltef.nl

Attachments:

t253486_1
0001-test_aio-Fix-broken-error-recovery-assertions-in-001.patchtext/x-patch; charset=utf-8; name=0001-test_aio-Fix-broken-error-recovery-assertions-in-001.patchDownload+5-6
#2Michael Paquier
michael@paquier.xyz
In reply to: Jelte Fennema-Nio (#1)
Re: test_aio: Fix broken error recovery assertions in 001_aio

On Wed, Aug 19, 2026 at 12:08:56PM +0200, Jelte Fennema-Nio wrote:

The three error recovery checks in `test_handle()` used `qr/^|ok$/` to
look for the `ok` marker column in psql's output. That is an alternation
of `^` and `ok$`, and `^` matches every string, so the assertions passed
no matter what psql printed.

Passing by..

Oops, /^|ok$/ with a '|' meaning OR in this context, or match all
strings. That's clearly broken, yes.

Will check later and fix. Thanks for the report.
--
Michael

#3Michael Paquier
michael@paquier.xyz
In reply to: Michael Paquier (#2)
Re: test_aio: Fix broken error recovery assertions in 001_aio

On Thu, Aug 20, 2026 at 08:18:02AM +0900, Michael Paquier wrote:

Will check later and fix. Thanks for the report.

Addressed that with 9d23f862d608, down to v18.
--
Michael