2026-06-01 · claude-opus-4-6

Set Notice Receiver Before libpq Connection Startup — May 2026 Summary

Problem

PostgreSQL's libpqsrv infrastructure (used by dblink, postgres_fdw, and other extensions for outbound libpq connections from within a backend) had a timing bug: the libpqsrv_notice_receiver callback — which routes remote NOTICE/WARNING messages through ereport() — was only installed after libpqsrv_connect() completed. Notices generated during connection establishment (e.g., from login event triggers on the remote server) bypassed structured logging and were dumped raw to stderr.

This broke the contract of the recently committed "Log remote NOTICE, WARNING, and similar messages using ereport()" feature.

Solution: Two-Phase Connection API

After an initial wrapper-function approach (V1) was rejected as too narrow, the accepted design splits libpqsrv_connect() into composable primitives:

libpqsrv_connect_start() / libpqsrv_connect_params_start() — Calls libpqsrv_connect_prepare() (which does AcquireExternalFD()) then PQconnectStart(). Returns PGconn* in a started-but-not-completed state.
libpqsrv_connect_complete() — Drives the async connection to completion (polling with WaitLatchOrSocket, handling interrupts).

Between these two calls, callers can invoke PQsetNoticeReceiver() or any other per-connection configuration. The existing libpqsrv_connect() convenience functions remain for callers that don't need the hook point.

Key Design Constraints

Resource cleanup contract: libpqsrv_connect_complete() must always be called (even if PQconnectStart() returns NULL) because AcquireExternalFD() already reserved an FD slot.
Double-free prevention: postgres_fdw uses a separate start_conn variable, only assigning to conn after libpqsrv_connect_complete() succeeds. This prevents both the inner (libpqsrv_connect_complete's PG_TRY/PG_CATCH) and outer (connect_pg_server's PG_CATCH) cleanup blocks from firing on the same connection.

Patch Evolution

Version	Key Change
V1	Dedicated wrapper functions (`libpqsrv_connect_with_notice_receiver()`) — rejected as ad-hoc
V2	Two-phase API introduced
V3	Style cleanup: removed unnecessary local `conn` variables in `_start` functions
V4	Removed redundant NULL checks before `PQsetNoticeReceiver()` (libpq handles NULL internally)

Outcome

Committed on 2026-05-22 by Fujii Masao. The two-phase API follows libpq's own design philosophy (PQconnectStart/PQconnectPoll) and provides a general extension point for any per-connection setup needed between connection initiation and completion.

2026-06-01 · claude-opus-4-6

Incremental Update: Post-Commit Whitespace Fix

Summary

This round contains only a minor cosmetic fix for a .gitattributes whitespace violation in the committed patch. There is no substantive technical progress or design discussion.

The Issue

Peter Eisentraut identified that commit 06a5c3cdef02 introduced a line in contrib/postgres_fdw/connection.c that uses spaces for indentation, violating the project's git whitespace rules (detected via git show --check). The offending line was a comment-annotated boolean argument:

                                                   /* expand_dbname = */ false);

The deep indentation (aligning with function parameters above) caused pgindent to produce space-based indentation that triggers the whitespace check.

Resolution

Fujii proposed reformatting to keep the /* expand_dbname = */ false comment style (consistent with libpqwalreceiver.c) but restructured the line to avoid the whitespace violation. Evan Chao had submitted an alternative fix, but Fujii's v2 was preferred and pushed. Both confirmed git show --check passes on the fix commit.

This is purely a formatting/style cleanup with zero functional impact.

Set notice receiver before libpq connection startup

Latest Update