Adding pg_dump flag for parallel export to pipes

First seen: 2025-04-07 17:16:58+00:00 · Messages: 25 · Participants: 7

Latest Update

2026-05-25 · claude-opus-4-6

New External Tester Report — First Substantive Feedback in Months

Solai (solai.cdac@gmail.com) provides the first external testing report since Mahendra's earlier reviews. The message confirms basic functionality works but surfaces a user-facing footgun around parallel workers writing to the same output file.

Key Technical Finding: Shared Output Target Corruption

Solai demonstrates that --pipe="gzip > dump.gz" with -j 4 causes multiple parallel workers to independently spawn gzip processes all targeting the same file, resulting in corrupted/truncated output:

gunzip -c dump.gz > dump.sql
gzip: dump.gz: unexpected end of file

This is not a bug per se — the %f placeholder exists precisely to differentiate per-file outputs — but the failure mode when users omit %f from the command template is silent data corruption rather than a clear error. This raises the question of whether:

  1. The patch should require %f in the template (or at least warn when it's absent with -j > 1), or
  2. Documentation alone is sufficient to guide users toward correct usage patterns like --pipe="gzip > dump_%f.gz".

This is a legitimate UX/safety concern that hasn't been raised before in the thread. The existing design assumes users understand that the directory format produces multiple files, but nothing prevents the obvious mistake of specifying a single output destination.

Other Observations (confirmatory, not new)

Significance

This is the first message to break the months-long holding pattern of author-only maintenance rebases. While it doesn't constitute committer review, it does introduce a new design question (guard against missing %f in parallel mode) that the patch author will likely need to address.

History (3 prior analyses)
2026-05-22 · claude-opus-4-6

No substantive progress

Another minimal maintenance drop from Nitin — adjusting how pipe commands are quoted in the Windows test. Single sentence description with no technical elaboration.

No design changes, no new reviewer engagement, no movement on any of the long-standing open items:

  • First three commits still unsquashed
  • LO TOC PG_BINARY_W unconditional-change still unresolved
  • pg_dumpall --pipe still deferred
  • No committer or reviewer response

The thread continues in its holding pattern: the author iterates on Windows test quoting while substantive review remains absent.


2026-05-18 · claude-opus-4-6

No substantive progress

Another minimal maintenance drop from Nitin — removing the split command from the Windows test path and rebasing against HEAD. Single sentence description with no technical elaboration.

No design changes, no new reviewer engagement, no movement on any of the long-standing open items:

  • First three commits still unsquashed
  • LO TOC PG_BINARY_W unconditional-change still unresolved
  • pg_dumpall --pipe still deferred
  • No committer or reviewer response

The thread continues in its holding pattern: the author maintains patch buildability and incrementally polishes test portability while substantive review remains absent.


2026-05-14 · claude-opus-4-6

No substantive progress

Yet another minimal maintenance drop from Nitin — this time addressing Windows backslash path handling in the test code. The message is a single sentence: "minor changes to the test code for windows backslash paths."

No design changes, no new reviewer engagement, no movement on any of the open items carried since v7:

  • First three commits still unsquashed
  • LO TOC PG_BINARY_W unconditional-change still unresolved
  • pg_dumpall --pipe still deferred
  • No committer or reviewer response

The thread remains in the same holding pattern: the author is iterating on platform portability minutiae while waiting for substantive review that continues not to materialize.