Buildfarm: Enabling injection points on basilisk/dogfish (Alpine / musl)
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.
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:t51430psql -h localhost -U postgresBuilt from patchset v3 (message #3), July 28, 2026 at 11:16 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 t51430_3 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t51430_3 && git checkout t51430_3Patchset v3 (message #3) is on t51430_3
I recently enabled more features on my two buildfarm animals basilisk
and dogfish, which are running on Alpine with musl-libc in a docker
container.
--with-libnuma and --with-liburing seemed to work fine and have been
enabled for the last few runs, but --enable-injection-points does not [1]https://github.com/technowledgy/postgresql-buildfarm-alpine/pull/100.
With injection points enabled, I get the following errors in test_aio:
[15:14:45.408](0.000s) not ok 187 - worker: first hard IO error is
reported: expected stderr
[15:14:45.409](0.000s)
[15:14:45.409](0.000s) # Failed test 'worker: first hard IO error is
reported: expected stderr'
# at t/001_aio.pl line 810.
[15:14:45.409](0.000s) # 'psql:<stdin>:88: ERROR:
could not read blocks 2..2 in file "base/5/16408": I/O error'
# doesn't match '(?^:ERROR:.*could not read blocks 2\.\.2 in file
\"base/.*\": Input/output error)'
5 more tests in that suite fail with similar errors. Full logs in the
artifact downloads of the CI run [2]https://github.com/technowledgy/postgresql-buildfarm-alpine/actions/runs/14420687470?pr=100.
It seems like it's just the error message that is different and has
"I/O" instead of "Input/output"?
On a more general note, does enabling injection points make any sense
here? I see that coverage in the build farm is not very big. IIUC, those
are a development tool, so might not be relevant, because nobody is
developing on Alpine / musl?
Best,
Wolfgang
[1]: https://github.com/technowledgy/postgresql-buildfarm-alpine/pull/100
[2]: https://github.com/technowledgy/postgresql-buildfarm-alpine/actions/runs/14420687470?pr=100
https://github.com/technowledgy/postgresql-buildfarm-alpine/actions/runs/14420687470?pr=100
On Sat, Apr 12, 2025 at 07:51:06PM +0200, Wolfgang Walther wrote:
With injection points enabled, I get the following errors in test_aio:
[15:14:45.408](0.000s) not ok 187 - worker: first hard IO error is reported:
expected stderr
[15:14:45.409](0.000s)
[15:14:45.409](0.000s) #�� Failed test 'worker: first hard IO error is
reported: expected stderr'
#�� at t/001_aio.pl line 810.
[15:14:45.409](0.000s) #������������������ 'psql:<stdin>:88: ERROR:� could
not read blocks 2..2 in file "base/5/16408": I/O error'
#���� doesn't match '(?^:ERROR:.*could not read blocks 2\.\.2 in file
\"base/.*\": Input/output error)'
It seems like it's just the error message that is different and has "I/O"
instead of "Input/output"?
Looks like it.
On a more general note, does enabling injection points make any sense here?
Yes, it does.
I see that coverage in the build farm is not very big. IIUC, those are a
development tool, so might not be relevant, because nobody is developing on
Alpine / musl?
No, whether anyone develops on the platform is not a factor. One hasn't fully
tested PostgreSQL until one builds with injection points.
On 2025-04-12 Sa 10:10 PM, Noah Misch wrote:
On Sat, Apr 12, 2025 at 07:51:06PM +0200, Wolfgang Walther wrote:
With injection points enabled, I get the following errors in test_aio:
[15:14:45.408](0.000s) not ok 187 - worker: first hard IO error is reported:
expected stderr
[15:14:45.409](0.000s)
[15:14:45.409](0.000s) # Failed test 'worker: first hard IO error is
reported: expected stderr'
# at t/001_aio.pl line 810.
[15:14:45.409](0.000s) # 'psql:<stdin>:88: ERROR: could
not read blocks 2..2 in file "base/5/16408": I/O error'
# doesn't match '(?^:ERROR:.*could not read blocks 2\.\.2 in file
\"base/.*\": Input/output error)'
It seems like it's just the error message that is different and has "I/O"
instead of "Input/output"?Looks like it.
On a more general note, does enabling injection points make any sense here?
Yes, it does.
I see that coverage in the build farm is not very big. IIUC, those are a
development tool, so might not be relevant, because nobody is developing on
Alpine / musl?No, whether anyone develops on the platform is not a factor. One hasn't fully
tested PostgreSQL until one builds with injection points.
Here's a simple fix ... also removes some unnecessary escaping and
leaning toothpick syndrome.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
Andrew Dunstan:
On 2025-04-12 Sa 10:10 PM, Noah Misch wrote:
On Sat, Apr 12, 2025 at 07:51:06PM +0200, Wolfgang Walther wrote:
With injection points enabled, I get the following errors in test_aio:
[15:14:45.408](0.000s) not ok 187 - worker: first hard IO error is
reported:
expected stderr
[15:14:45.409](0.000s)
[15:14:45.409](0.000s) # Failed test 'worker: first hard IO error is
reported: expected stderr'
# at t/001_aio.pl line 810.
[15:14:45.409](0.000s) # 'psql:<stdin>:88: ERROR: could
not read blocks 2..2 in file "base/5/16408": I/O error'
# doesn't match '(?^:ERROR:.*could not read blocks 2\.\.2 in file
\"base/.*\": Input/output error)'
It seems like it's just the error message that is different and has
"I/O"
instead of "Input/output"?Looks like it.
On a more general note, does enabling injection points make any
sense here?Yes, it does.
I see that coverage in the build farm is not very big. IIUC, those
are a
development tool, so might not be relevant, because nobody is
developing on
Alpine / musl?No, whether anyone develops on the platform is not a factor. One
hasn't fully
tested PostgreSQL until one builds with injection points.Here's a simple fix ... also removes some unnecessary escaping and
leaning toothpick syndrome.
Confirmed - this works!
Thanks,
Wolfgang
Hi,
On April 13, 2025 7:27:33 PM GMT+02:00, Wolfgang Walther <walther@technowledgy.de> wrote:
Andrew Dunstan:
On 2025-04-12 Sa 10:10 PM, Noah Misch wrote:
On Sat, Apr 12, 2025 at 07:51:06PM +0200, Wolfgang Walther wrote:
With injection points enabled, I get the following errors in test_aio:
[15:14:45.408](0.000s) not ok 187 - worker: first hard IO error is reported:
expected stderr
[15:14:45.409](0.000s)
[15:14:45.409](0.000s) # Failed test 'worker: first hard IO error is
reported: expected stderr'
# at t/001_aio.pl line 810.
[15:14:45.409](0.000s) # 'psql:<stdin>:88: ERROR: could
not read blocks 2..2 in file "base/5/16408": I/O error'
# doesn't match '(?^:ERROR:.*could not read blocks 2\.\.2 in file
\"base/.*\": Input/output error)'
It seems like it's just the error message that is different and has "I/O"
instead of "Input/output"?Looks like it.
On a more general note, does enabling injection points make any sense here?
Yes, it does.
I see that coverage in the build farm is not very big. IIUC, those are a
development tool, so might not be relevant, because nobody is developing on
Alpine / musl?No, whether anyone develops on the platform is not a factor. One hasn't fully
tested PostgreSQL until one builds with injection points.Here's a simple fix ... also removes some unnecessary escaping and leaning toothpick syndrome.
Confirmed - this works!
Thanks for testing and writing up a fix. Andrew, would you be ok applying it? I've been traveling the last 24h and should probably not handing sharp commit bits tonight.
I'm not too surprised about failures like this, when writing the tests up I was worried about different formulations. But after seeing freebsd, glibc Linux, netbsd, openbsd windows all working the same I thought we were in the clear.
Greetings,
Andres
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
On 2025-04-13 Su 1:51 PM, Andres Freund wrote:
Hi,
On April 13, 2025 7:27:33 PM GMT+02:00, Wolfgang Walther <walther@technowledgy.de> wrote:
Andrew Dunstan:
On 2025-04-12 Sa 10:10 PM, Noah Misch wrote:
On Sat, Apr 12, 2025 at 07:51:06PM +0200, Wolfgang Walther wrote:
With injection points enabled, I get the following errors in test_aio:
[15:14:45.408](0.000s) not ok 187 - worker: first hard IO error is reported:
expected stderr
[15:14:45.409](0.000s)
[15:14:45.409](0.000s) # Failed test 'worker: first hard IO error is
reported: expected stderr'
# at t/001_aio.pl line 810.
[15:14:45.409](0.000s) # 'psql:<stdin>:88: ERROR: could
not read blocks 2..2 in file "base/5/16408": I/O error'
# doesn't match '(?^:ERROR:.*could not read blocks 2\.\.2 in file
\"base/.*\": Input/output error)'
It seems like it's just the error message that is different and has "I/O"
instead of "Input/output"?Looks like it.
On a more general note, does enabling injection points make any sense here?
Yes, it does.
I see that coverage in the build farm is not very big. IIUC, those are a
development tool, so might not be relevant, because nobody is developing on
Alpine / musl?No, whether anyone develops on the platform is not a factor. One hasn't fully
tested PostgreSQL until one builds with injection points.Here's a simple fix ... also removes some unnecessary escaping and leaning toothpick syndrome.
Confirmed - this works!
Thanks for testing and writing up a fix. Andrew, would you be ok applying it? I've been traveling the last 24h and should probably not handing sharp commit bits tonight.
I'm not too surprised about failures like this, when writing the tests up I was worried about different formulations. But after seeing freebsd, glibc Linux, netbsd, openbsd windows all working the same I thought we were in the clear.
pushed.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com