“1,024 counters” is a misleading way to describe a reported PostgreSQL 18 issue: the number refers to local buffers for temporary-table pages, not SQL counters or a universal table-size limit. In a specific reproducer, sequential-scan look-ahead pinned all 1,024 buffers, leaving none available when PostgreSQL needed another buffer to fetch a TOASTed value.
What does temp_buffers control?
temp_buffers sets the maximum memory available for temporary-table buffers within each database session. These buffers hold pages from temporary tables; the setting does not count SQL counters, and it is separate from memory used by other query operations. PostgreSQL 18 documents a default of 8MB. Buffers are allocated as needed up to the configured maximum, rather than reserving the whole amount at session start. PostgreSQL 18 resource configuration documentation.
As an Amazon Associate I earn from qualifying purchases.
A session can change temp_buffers only before its first use of a temporary table. Once a temporary table has been used in that session, changing the setting has no effect for that session.
Recommended Free Tools
How did the reported 1,024-buffer failure happen?
In a PostgreSQL mailing-list report dated July 3, 2026, Xuneng Zhou described a PostgreSQL 18 reproducer in which sequential-scan ReadStream look-ahead could pin the entire local-buffer pool. The report’s 1,024-buffer figure is the pool size in its default-temp_buffers example, not a universal limit on temporary-table size. Xuneng Zhou’s PostgreSQL mailing-list report.
#1 Best Overall
Look-ahead filled the pool
The reproducer used io_combine_limit=16. With effective_io_concurrency set to 64 or higher, the report says the look-ahead formula could exceed the 1,024-buffer pool, allowing the pin limit to reach all of its local buffers. The temporary table contained approximately 1,333 heap blocks, and the scan filled its look-ahead window during a cold-miss run.
A TOAST fetch needed another buffer
The scan’s output rows also included a TOASTed column. Fetching that value required another buffer; in the reported scenario, all 1,024 local buffers were already pinned, so the additional request failed. The failure therefore depended on the combination of look-ahead, a cold-miss scan, and a need to fetch TOASTed data—not simply on a temporary table exceeding 1,024 blocks.
Zhou cautioned that the timing conditions may be difficult to reproduce in changing production workloads. The report describes a conditional failure mode, not evidence that every PostgreSQL deployment or every table larger than the pool will fail. The cited evidence does not establish whether releases beyond the reported PostgreSQL 18 build are affected or whether a fix has since shipped.
How are temp_buffers, work_mem, and temp_file_limit different?
| Setting | Scope | Resource it governs | What happens at the limit |
|---|---|---|---|
temp_buffers |
Per database session | Buffers for pages of temporary tables | Caps the session’s temporary-table buffer pool; the reported failure occurred when a request needed another buffer while all available local buffers were pinned. PostgreSQL 18 documentation gives a default of 8MB. |
work_mem |
Per query operation, with multiple operations and concurrent sessions able to consume memory separately | Memory for operations such as sorts and hash tables before they write temporary files; hash operations are also governed by hash_mem_multiplier |
An operation may write temporary files when it exceeds its available working memory. See the PostgreSQL 17 resource configuration documentation. |
temp_file_limit |
Per process | Behind-the-scenes temporary files, including files for sorts, hashes, and held cursors | Limits those temporary files. Explicit temporary-table storage is excluded. See the PostgreSQL 17 resource configuration documentation. |
These settings govern different resources. Temporary-table pages use temp_buffers; query operations that spill use temporary files, with their memory use governed by work_mem; and temp_file_limit limits certain files rather than explicit temporary-table storage. Raising one setting is not established by this report as a general fix for the described failure.
Rank #3
Does temp_file_limit apply to temporary tables?
It does not cap explicit temporary-table storage. It applies to temporary files created behind the scenes by a process, such as files used by sorts, hashes, or held cursors. A temporary table can still consume its session’s temp_buffers independently of that file limit.
Quick Recap
Best Value
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
