PG19 Beta3: adapt COPY failure tests to psql input draining

[ibrahim halatci (ihalatci)]

Summary

PostgreSQL psql change d6ab88d, first present in PG19 Beta3, changed failed COPY input draining. These four failure injections abort before COPY_IN, so inline \copy ... FROM STDIN input can consume following SQL in psql echo-all regression scripts.

• replace the three affected failure_copy_to_reference inputs and one affected failure_copy_on_hash input unconditionally with zero-row client-side FROM PROGRAM 'true'
• keep the server-side Citus failure injection, errors, placement checks, and row-count assertions unchanged
• update only the four corresponding echoed commands in the canonical expected files
• use no version gate, alternative expected output, harness change, normalization, or global machinery

\copy ... FROM PROGRAM is client-side and works consistently across the supported clients tested here, while supplying no rows for failures that occur before COPY_IN.

Validation

Exact commit/tree validated: 4ee87f66cf0bfbff7447df0e5da9dc24e9f30fd1 / aef35426123a65d79cda324a583736fab67b1cf8.

Focused affected schedule:

• PG19 Beta3: 6/6
• PG19 Beta2: 6/6
• PG18.4: 6/6

Full check-failure:

• PG19 Beta3: 38/38 (94 seconds)
• PG19 Beta2: 38/38 (99 seconds)
• PG18.4: 38/38 (105 seconds)
• PG17.10: 38/38 (95 seconds)
• PG16.14: 38/38 (93 seconds)

PG19 Beta2 validation used the existing isolated local compatibility shim that omits the Beta3-only output_plugin_libraries test setting; the shim is not part of this PR and was restored after validation.

Final diff: 4 files, 8 insertions, 8 deletions.

Closes #8780

[ibrahim halatci (ihalatci)]

Validation note: PG18/17/16 full 38/38 results were captured at the immediately preceding gate commit; exact-final b5dafddc builds and synthetic gate tests pass. Exact-final full legacy schedule reruns are queued to close this conservative validation gap.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 88.75%. Comparing base (866ab1b) to head (aed7ea3).
⚠️ Report is 6 commits behind head on pg19-support.

Additional details and impacted files

@@               Coverage Diff                @@
##           pg19-support    #8784      +/-   ##
================================================
+ Coverage         88.69%   88.75%   +0.05%     
================================================
  Files               289      289              
  Lines             65062    65070       +8     
  Branches           8200     8200              
================================================
+ Hits              57709    57753      +44     
+ Misses             4984     4954      -30     
+ Partials           2369     2363       -6     

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Colm (colm-mchugh)]

The PR states a goal of keeping both canonical .out files byte-identical. But is that possible once the .sql test file has control lines, e.g. \gset, \if, \else, etc ? Asking because pg_regress runs psql with ECHO=all, which echoes every line - including those in the branch that is not taken. This appears to be the case with the PR's failure_copy_to_reference_1.out, specifically the \copy ... FROM PROGRAM 'true' line, even though that branch never runs. The consequence seems to be permanently dead or stale output (.out). As an alternative, how about promoting the _1.out to the canonical output file and keep a single _0.out for Beta3+ clients.

[Colm (colm-mchugh)]

Fundamental question, is the version gate actually needed ? What concrete regression does it prevent? Asking because #8780's own "Minimum Fix" is the unconditional FROM PROGRAM 'true' change, and it's validation records that "Fixed PG19 Beta3, Beta2 and PG18.4: 38/38 pass".

\copy ... FROM PROGRAM is purely client-side; nothing about it is version-dependent, so server-side assertions are identical on PG16-19. If that holds, the unconditional fix is ~4 changed lines in 2 .sql files plus 4 echo lines in the 2 canonical .out files. The linked activity note says the release-review correction was "gate on the invoking psql client, not server_version_num"- i.e. it corrected which version to gate on, not that gating was required. The question of whether to gate at all appears to have been skipped - please clarify.

[ibrahim halatci (ihalatci)]

Addressing the canonical/alternative-output question and the fundamental gate question: agreed—the gate was unnecessary. I removed the version gate, all conditional control lines, and all four alternative expected files. The four client-side zero-row inputs now use FROM PROGRAM 'true' unconditionally, while the server-side COPY failure injection, errors, placement checks, and row-count assertions are unchanged. The canonical outputs contain only the four corresponding echoed command substitutions, so there is no inactive-branch or stale transcript.

At exact head 4ee87f66cf0bfbff7447df0e5da9dc24e9f30fd1, focused tests passed 6/6 on PG19 Beta3, PG19 Beta2, and PG18.4. Full check-failure passed 38/38 on PG19 Beta3, PG19 Beta2, PG18.4, PG17.10, and PG16.14.

[Colm (colm-mchugh)]

Lgtm, one non-blocking comment nit.