On Wed, May 20, 2026 at 4:21 PM Chao Li <[email protected]> wrote: > > Hi, > > While testing “Log remote NOTICE, WARNING, and similar messages using > ereport()”, I noticed that libpqsrv_notice_receiver is only installed after > libpqsrv_connect() finishes. As a result, NOTICE messages generated during > connection establishment are missed by ereport() and are still printed to > stderr. > > To reproduce the issue, I created a separate database called remotedb and > defined a login trigger that emits a NOTICE message: > ``` > CREATE DATABASE remotedb; > > \c remotedb > > CREATE OR REPLACE FUNCTION repro_login_notice() > RETURNS event_trigger > LANGUAGE plpgsql AS $$ > BEGIN > RAISE NOTICE 'startup notice from remotedb login trigger'; > END; > $$; > > CREATE EVENT TRIGGER repro_login_notice_trg > ON login > EXECUTE FUNCTION repro_login_notice(); > > ALTER EVENT TRIGGER repro_login_notice_trg ENABLE ALWAYS; > ``` > > Then, from another database: > ``` > evantest=# create extension dblink; > CREATE EXTENSION > evantest=# SELECT dblink_connect('host=127.0.0.1 port=5432 dbname=remotedb > user=chaol sslmode=disable gssencmode=disable'); > dblink_connect > ---------------- > OK > (1 row) > ``` > > In the system log, the NOTICE message is printed directly: > ``` > 2026-05-20 13:02:19.350 CST [24909] STATEMENT: SELECT > dblink_connect('host=127.0.0.1 port=5432 dbname=remotedb user=chaol > sslmode=disable gssencmode=disable'); > NOTICE: startup notice from remotedb login trigger > ``` > > To fix that, I think we should install libpqsrv_notice_receiver before > libpqsrv_connect_internal(). In the attached patch, I added two helpers: > libpqsrv_connect_with_notice_receiver() and > libpqsrv_connect_params_with_notice_receiver(). > > With the fix, the NOTICE message now looks like this: > ``` > 2026-05-20 14:44:49.296 CST [45567] LOG: received message via remote > connection: NOTICE: startup notice from remotedb login trigger > 2026-05-20 14:44:49.296 CST [45567] STATEMENT: SELECT > dblink_connect('host=127.0.0.1 port=5432 dbname=remotedb user=chaol > sslmode=disable gssencmode=disable'); > ``` > > Please see the attached patch for details.
Thanks for the report and patch! I'd prefer to avoid adding notice-receiver-specific wrappers such as libpqsrv_connect_with_notice_receiver(). Instead, how about splitting libpqsrv_connect() into two steps: libpqsrv_connect_start(), which performs libpqsrv_connect_prepare() and PQconnectStart(), and libpqsrv_connect_complete(), which runs libpqsrv_connect_internal()? With this approach, callers could invoke PQsetNoticeReceiver() after libpqsrv_connect_start() returns but before libpqsrv_connect_complete() is called. This would allow startup-time notices to be handled correctly without introducing a dedicated wrapper function. Compared to the *_with_notice_receiver() approach, this design is more general because it exposes the phase between PQconnectStart() and connection completion. It could also support other kinds of per-connection setup in the future, not just notice receiver installation. Thought? Regards, -- Fujii Masao
