Re: BUG #19348: Disk space error when running COPY after upgrading to PostgreSQL 17.7
| От | Thomas Munro |
|---|---|
| Тема | Re: BUG #19348: Disk space error when running COPY after upgrading to PostgreSQL 17.7 |
| Дата | |
| Msg-id | CA+hUKG+zqLrYwkHE4a86JZyKkyKRC+LnX5L2x3Sunop=x=7V9Q@mail.gmail.com обсуждение исходный текст |
| Ответ на | BUG #19348: Disk space error when running COPY after upgrading to PostgreSQL 17.7 (PG Bug reporting form <noreply@postgresql.org>) |
| Список | pgsql-bugs |
On Wed, Dec 10, 2025 at 12:32 AM PG Bug reporting form <noreply@postgresql.org> wrote: > The following bug has been logged on the website: > > Bug reference: 19348 > Logged by: weijie JL > Email address: weijie1006jl@gmail.com > PostgreSQL version: 17.7 > Operating system: RockyLinux8 > Description: > > After upgrading to PostgreSQL 17.7, our scheduled data synchronization task > intermittently fails. About 6 seconds into the run, during the COPY import > stage, we get the following error: > > ERROR: 53100: could not extend file "base/16416/4201185432" with > FileFallocate(): No space left on device > However, the disk has ample free space. We see no abnormal data size growth, > and the table involved is small — roughly a dozen columns, each containing > short text strings of only a few dozen characters. Could this be a case of the mysterious ENOSPC reported by XFS since we started using posix_fallocate() in COPY? IIRC that's Rocky's default file system. I'm working on a patch that would allow the next minor releases to turn that off, originally for the benefit of BTRFS compression users but it was pointed out[1] that XFS users might want this too until the root cause can be figured out. (Passing thought: I don't recall anyone reproducing this on Debian systems, I know I tried... could RHEL/Rocky have a local difference?) [1] https://www.postgresql.org/message-id/flat/CAKZiRmzF6SRR%2BAxPZsXzs1kaHrxjLO2sbLT4Q61EMA5PGQB3Vg%40mail.gmail.com#b07d8e3bcef37e9afda96e0333cb1454
В списке pgsql-bugs по дате отправления: