Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1xB6Ou-000000030R0-0Zaq for pgsql-bugs@arkaria.postgresql.org; Mon, 28 Sep 2026 08:07:52 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xB6Ot-00000008Ihw-0l9p for pgsql-bugs@arkaria.postgresql.org; Mon, 28 Sep 2026 08:07:51 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1xB28x-00000007Sou-0oce for pgsql-bugs@lists.postgresql.org; Mon, 28 Sep 2026 03:35:07 +0000 Received: from mahout.postgresql.org ([2001:4800:3e1:1::227]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1xB28u-00000001c5G-2gLe for pgsql-bugs@lists.postgresql.org; Mon, 28 Sep 2026 03:35:06 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=postgresql.org; s=20171124; h=Message-ID:Date:Reply-To:Cc:From:To:Subject: Content-Transfer-Encoding:MIME-Version:Content-Type:Sender:Content-ID: Content-Description:In-Reply-To:References; bh=i6qHTs1rsjw4ccuhdKsCRuDFgms+1972Qz0g18AR3ag=; b=Dh1ztb5SryPzi0eNnPMx61SbQ/ 8CbQyZZm/4qRg5ROwwUZR/XmoYHWqMEuviCryB89JiYC9u7Fdik/2Uk6oMlVr3J0rlxETDqEKCMk8 bdRHvF2RxpLeRZYeiLwrzVHbtfOyO6klr1iBuwLSFJBTappSQVw//os4YXS5tPI5/fSbC4C3PqHm8 IyRpaUOaIYWFyewBasX54N5y3BA6FbD/fe35+Gq8bRLIyjeShtHlD6ZOJ9tjljSxia1BYfqwRiukG pJR6ePz/wT1DZNJYON+J4lcfMWGB50BUS3/2OKHHwISNr5Z9noORoTrPVdmEeEklg2MOC3RlPDGvk 16KKfUig==; Received: from wrigleys.postgresql.org ([2a02:16a8:dc51::60]) by mahout.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1xB28v-004nUI-0A for pgsql-bugs@lists.postgresql.org; Mon, 28 Sep 2026 03:35:05 +0000 Received: from localhost ([127.0.0.1] helo=wrigleys.postgresql.org) by wrigleys.postgresql.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xB28s-0000000E9Xf-3rqA for pgsql-bugs@lists.postgresql.org; Mon, 28 Sep 2026 03:35:03 +0000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: BUG #19725: PostgreSQL 18.6: pg_restore read failure with io_uring, not observed with worker To: pgsql-bugs@lists.postgresql.org From: PG Bug reporting form Cc: weijie1006jl@gmail.com Reply-To: weijie1006jl@gmail.com, pgsql-bugs@lists.postgresql.org Date: Mon, 28 Sep 2026 03:34:53 +0000 Message-ID: <19725-a209093fc33dfb3e@postgresql.org> X-Auto-Response-Suppress: All Auto-Submitted: auto-generated List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk The following bug has been logged on the website: Bug reference: 19725 Logged by: weijie JL Email address: weijie1006jl@gmail.com PostgreSQL version: 18.6 Operating system: RockyLinux9 Description: =20 Hello, I can reproduce a read failure during pg_restore with io_method=3Dio_uring. The error disappears with worker and recurs after switching back to io_uring. Environment: - PostgreSQL 18.6, x86_64 - VMware VM: 8 vCPUs, 32 GB RAM - Kernel: 5.14.0-611.55.1.el9_7.x86_64 Settings: effective_io_concurrency =3D 256 maintenance_io_concurrency =3D 16 max_parallel_maintenance_workers =3D 2 Restore command: nohup pg_restore -d test001 dhr.dump/ -j8 -v > test.log 2>&1 & One failing statement: ALTER TABLE ONLY dhr.obj_permission_object ADD CONSTRAINT obj_permission_object_pkey PRIMARY KEY (id); Server error: ERROR: could not read blocks 143..158 in file "base/1684908/1686127": Operation canceled LOCATION: md_readv_report, md.c:2059 SQLSTATE: XX000 Observed test sequence: 1. io_method=3Dio_uring: the read error occurred during index creation. 2. Changed io_method to worker: retried without errors. 3. Changed io_method back to io_uring: the read error was reproduced. I have not measured the failure rate or prepared a self-contained minimal reproducer. One earlier run also reported "could not map dynamic shared memory segment" from parallel workers immediately after the read error. Those DSM errors have not recurred in subsequent failing tests. Does this match a known PostgreSQL bug or kernel-side io_uring issue? What additional logs or tracing would help identify the cause? Thank you.