Re: BUG #19511: contrib/dblink: NULL dereference in dblink_get_notify() when called without a prior connection

On Fri, Jun 5, 2026 at 7:55 PM Amjad Shahzad <amjadshahzad2000(at)gmail(dot)com> wrote:
>
> Hi Fujii,
>
> You are correct. I checked the libpq source and both PQconsumeInput() and PQnotifies() have explicit NULL guards:
>
> /* fe-exec.c line 2003 */
> if (!conn)
> return 0;
>
> /* fe-exec.c line 2688 */
> if (!conn)
> return NULL;
>
> So no segmentation fault actually occurs. The function silently returns 0 rows when called without a prior connection instead of crashing.
>
> The real issue is a behavioral inconsistency: every other dblink function that uses the default connection explicitly checks for NULL
> and calls dblink_conn_not_avail() to give a clear error message.
>
> dblink_get_notify() is the only exception, it silently returns an empty result set, which could mislead callers into thinking no
> notifications exist when in fact no connection was established.

dblink_get_notify() was introduced by commit f4095b4c4b2 in 2009,
and it appears to have behaved this way ever since. So there may be
existing systems that depend on the current behavior. Also, there do not
seem to have been any complaints about it over the past 10+ years.

Therefore, unless the current behavior can be shown to cause actual
issues or risks, I'm just feeling tempted to avoid changing it...
At the very least, I don't think we should change the behavior in
the back branches. Thought?

Regards,

--
Fujii Masao