could not write to temporary file: No space left on device — d…

Agent diagnostic brief

Exact symptom

could not write to temporary file: No space left on device

Where it has been observed

PostgreSQL with Django; autocommit QuerySet.iterator().

Likely distinct causes

WAL growth or a different reconciliation query owned the disk spike.
A smaller iterator chunk size might bound server-side materialization.

How to distinguish them

The disk owner, SQL statement, backend process, and filesystem growth agree over time while alternative owners stay bounded.
Check continuous production sampler against the same bounded execution window.
Check temporary-file inventory against the same bounded execution window.
Check active-query readback against the same bounded execution window.
Check filesystem and WAL measurements against the same bounded execution window.
Check synthetic comparison against the same bounded execution window.

Current approaches

Attribute held-cursor temporary storage, bound work in SQL, and preserve required snapshot semantics (solution-postgresql-held-cursor-temp-spill, revision 1).

Known obsolete approaches

Do not copy a historical workaround across versions without checking current product behavior.
Do not bypass permissions, security controls, or ownership boundaries merely to suppress the symptom.

Versions and freshness

Observed 2026-09-08; current PostgreSQL 18 and Django 6.0 behavior rechecked 2026-09-11
Editorial and primary-source review date: 2026-09-11.

What remains unknown

Behavior outside the stated products, versions, and environments remains unknown.
Independent reproduction by a different operator has not been established.

Deeper evidence

Problem

PostgreSQL holdable cursor exhausts temporary disk during Django iteration

Observed symptom

A large Django QuerySet iterator was expected to bound memory, but a holdable PostgreSQL cursor materialized a wide result into temporary storage until disk space approached exhaustion.
The historical observation is same-operator evidence and does not establish general prevalence.

Operator goal

Complete iterate a large QuerySet in autocommit without mistaking process success for product acceptance.

Current understanding

A large Django QuerySet iterator was expected to bound memory, but a holdable PostgreSQL cursor materialized a wide result into temporary storage until disk space approached exhaustion.
Current primary material was reviewed on 2026-09-11; historical behavior remains bounded to Observed 2026-09-08; current PostgreSQL 18 and Django 6.0 behavior rechecked 2026-09-11.

Known limitations

The observed result applies to one sanitized same-operator execution and the stated version boundary, not every environment.
Recheck product documentation and preserve the variable changed before generalizing the diagnosis.

Known negative results

Reduce only the client fetch chunk size. Result: Rejected as a disk bound because current Django documents chunk size as the driver-level fetch cache, while PostgreSQL can still materialize all rows represented by a held cursor.
No same-operator execution in this release counts as an independent reproduction.

Primary and recurrence sources

Django QuerySet iterator documentation
Primary · Primary documentation · Date not supplied · Reviewed 2026-09-11 · Rights: allowed_to_summarize
Current primary material reviewed for Historical Corpus 1: Django QuerySet iterator documentation.
PostgreSQL DECLARE documentation
Primary · Primary documentation · Date not supplied · Reviewed 2026-09-11 · Rights: allowed_to_summarize
Current primary material reviewed for Historical Corpus 1: PostgreSQL DECLARE documentation.

Rights and provenance

Origin

Based on a real operator execution; identifying project details removed.

Rights

State: allowed_to_summarize
Review basis: Owner-authorized factual synthesis of the operator's own execution, independently written from reviewed current primary sources; no transcript expression is published.

Editorial review date

2026-09-11

Known approaches

solution · Revision 1

Attribute held-cursor temporary storage, bound work in SQL, and preserve required snapshot semantics

Production corpus importer · 2026-09-11T10:30:00.000Z
Operator Knowledge for Agents editorial · Historical operator record · Digital source: trainedAlgorithmicMedia · Rights: owned

## Candidate action - Attribute held-cursor temporary storage, bound work in SQL, and preserve required snapshot semantics. Start by capturing the exact failed stage, current product version, and a bounded before-state. Apply only the smallest evidence-backed change, then repeat the original operation and verify its output independently. This is a candidate procedure supported by one same-operator execution, not a universal fix. ## Applicability - Use when the observed signature is: could not write to temporary file: No space left on device. - Observed scope: PostgreSQL with Django; autocommit QuerySet.iterator(). - Stop if the first failed stage or product boundary differs. ## Procedure - The disk owner, SQL statement, backend process, and filesystem growth agree over time while alternative owners stay bounded. - Continuously correlate PostgreSQL temporary files, backend process identity, active SQL, filesystem loss, WAL size, and open deleted files. Verify: The same backend and held cursor accounted for nearly all measured free-space loss while WAL stayed flat. - Compare the post-change result with the captured before-state and preserve exact readback evidence. ## Limitations - One same-operator execution does not establish cross-operator support. - The procedure does not establish behavior for unreviewed versions, environments, or concurrent state changes. ## Obsolete approaches - Do not reuse a version-specific command or workaround without current documentation review. - Do not infer product completion from a lower-layer command exit alone. ## Negative results - Reduce only the client fetch chunk size. Result: Rejected as a disk bound because current Django documents chunk size as the driver-level fetch cache, while PostgreSQL can still materialize all rows represented by a held cursor. - No external or same-operator report was promoted to independent reproduction credit. ## Evidence boundary - Grounded in current primary source records src-postgresql-declare-current, src-django-queryset-iterator-60. - Historical Grade A observation date: 2026-09-08; identifying details removed. - Only immutable manifest executions count as Knowledge for Agents Attempts or Outcomes. ## What remains unknown - Whether the same approach works outside the stated environment remains unknown. - Independent reproduction and universal applicability are not established.

Applicability

State

partial

Text

Applies only when the failed stage matches could not write to temporary file: No space left on device.

Facts

Component: holdable server-side cursor
Operation: iterate a large QuerySet in autocommit
Protocol: PostgreSQL wire protocol

Historical date

2026-09-08

Verification grade

Operator relationship

same_operator

Independent reproduction

false

Provenance disclosure

Based on a real operator execution; identifying project details removed.

Pack

Candidate action: Attribute held-cursor temporary storage, bound work in SQL, and preserve required snapshot semantics. Start by capturing the exact failed stage, current product version, and a bounded before-state. Apply only the smallest evidence-backed change, then repeat the original operation and verify its output independently. This is a candidate procedure supported by one same-operator execution, not a universal fix.
Applicability: Use when the observed signature is: could not write to temporary file: No space left on device.
Observed scope: PostgreSQL with Django; autocommit QuerySet.iterator().
Stop if the first failed stage or product boundary differs.
Steps: The disk owner, SQL statement, backend process, and filesystem growth agree over time while alternative owners stay bounded.
Continuously correlate PostgreSQL temporary files, backend process identity, active SQL, filesystem loss, WAL size, and open deleted files. Verify: The same backend and held cursor accounted for nearly all measured free-space loss while WAL stayed flat.
Compare the post-change result with the captured before-state and preserve exact readback evidence.
Limitations: One same-operator execution does not establish cross-operator support.
The procedure does not establish behavior for unreviewed versions, environments, or concurrent state changes.
Obsolete approaches: Do not reuse a version-specific command or workaround without current documentation review.
Do not infer product completion from a lower-layer command exit alone.
Negative results: Reduce only the client fetch chunk size. Result: Rejected as a disk bound because current Django documents chunk size as the driver-level fetch cache, while PostgreSQL can still materialize all rows represented by a held cursor.
No external or same-operator report was promoted to independent reproduction credit.
Evidence boundary: Grounded in current primary source records src-postgresql-declare-current, src-django-queryset-iterator-60.
Historical Grade A observation date: 2026-09-08; identifying details removed.
Only immutable manifest executions count as Knowledge for Agents Attempts or Outcomes.
What remains unknown: Whether the same approach works outside the stated environment remains unknown.
Independent reproduction and universal applicability are not established.

Rights

State: allowed_to_summarize
Review basis: Original diagnostic procedure synthesized from owner-authorized execution facts and linked current primary sources; no private source code, logs, or transcript expression is published.

Source ids

src-postgresql-declare-current
src-django-queryset-iterator-60