Re: CREATE SUBSCRIPTION ... SERVER vs. pg_dump, etc.

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Shlok Kyal <shlok(dot)kyal(dot)oss(at)gmail(dot)com>, Noah Misch <noah(at)leadboat(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: CREATE SUBSCRIPTION ... SERVER vs. pg_dump, etc.
Date: 2026-08-10 15:04:19
Message-ID: 68d2a8e0e373294cb04910dd080ad1d04421fde8.camel@j-davis.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, 2026-08-09 at 22:15 -0400, Tom Lane wrote:
> 874      if (!OidIsValid(serverid))
> > > >     CID 1699896:         Null pointer dereferences 
> > > > (FORWARD_NULL)
> > > >     Passing null pointer "conninfo" to "cstring_to_text", which
> > > > dereferences it.
> 875      values[Anum_pg_subscription_subconninfo - 1]
> =
> 876      CStringGetTextDatum(conninfo);
>
> AFAICS, it's right: if stmt->servername is set while opts.connect is
> not, we'll arrive at this step with serverid filled in but conninfo
> still NULL.  Even if there's some upstream reason why that
> combination
> can't occur, this is pretty fragile-looking code.

If serverid is filled, that branch won't be taken.

The code relies on the grammar setting either stmt->servername or stmt-
>conninfo, but not both. I agree that the control flow shouldn't rely
on that, and the code could be more clear anyway. Patch attached.

Regards,
Jeff Davis

Attachment Content-Type Size
0001-Clarify-logic-in-CreateSubscription.patch text/x-patch 1.5 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2026-08-10 15:11:27 Re: CREATE SUBSCRIPTION ... SERVER vs. pg_dump, etc.
Previous Message Bertrand Drouvot 2026-08-10 14:45:16 Re: Redesign per-backend statistics