MIME-Version: 1.0
References: <A2B8B7DE-C119-492F-A9FA-14CF86849777@gmail.com>
In-Reply-To: <A2B8B7DE-C119-492F-A9FA-14CF86849777@gmail.com>
From: Fujii Masao <masao.fujii@gmail.com>
Date: Wed, 20 May 2026 18:19:51 +0900
Message-ID: 
 <CAHGQGwHnz7FoSx+qQsAHBx_j8Tks+SC-kAPTevrKYfrL08Ee9Q@mail.gmail.com>
Subject: Re: Set notice receiver before libpq connection startup
To: Chao Li <li.evan.chao@gmail.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>,
 vignesh C <vignesh21@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAHGQGwHnz7FoSx%2BqQsAHBx_j8Tks%2BSC-kAPTevrKYfrL08Ee9Q%40mail.gmail.com>
Precedence: bulk

On Wed, May 20, 2026 at 4:21=E2=80=AFPM Chao Li <li.evan.chao@gmail.com> wr=
ote:
>
> Hi,
>
> While testing =E2=80=9CLog remote NOTICE, WARNING, and similar messages u=
sing ereport()=E2=80=9D, I noticed that libpqsrv_notice_receiver is only in=
stalled after libpqsrv_connect() finishes. As a result, NOTICE messages gen=
erated during connection establishment are missed by ereport() and are stil=
l 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=3D# create extension dblink;
> CREATE EXTENSION
> evantest=3D# SELECT dblink_connect('host=3D127.0.0.1 port=3D5432 dbname=
=3Dremotedb user=3Dchaol sslmode=3Ddisable gssencmode=3Ddisable');
>  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('ho=
st=3D127.0.0.1 port=3D5432 dbname=3Dremotedb user=3Dchaol sslmode=3Ddisable=
 gssencmode=3Ddisable');
> NOTICE:  startup notice from remotedb login trigger
> ```
>
> To fix that, I think we should install libpqsrv_notice_receiver before li=
bpqsrv_connect_internal(). In the attached patch, I added two helpers: libp=
qsrv_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 con=
nection: NOTICE:  startup notice from remotedb login trigger
> 2026-05-20 14:44:49.296 CST [45567] STATEMENT:  SELECT dblink_connect('ho=
st=3D127.0.0.1 port=3D5432 dbname=3Dremotedb user=3Dchaol sslmode=3Ddisable=
 gssencmode=3Ddisable');
> ```
>
> 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 witho=
ut
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 connectio=
n
completion. It could also support other kinds of per-connection setup in th=
e
future, not just notice receiver installation. Thought?

Regards,

--=20
Fujii Masao