Re: Some doubious code in pgstat.c

From: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
To: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Some doubious code in pgstat.c
Date: 2020-11-05 04:14:20
Message-ID: CAD21AoB3+qwz+mGO=RVVovE-r8sj=OS8KBQn5O0OO5Cgd3Wosg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Nov 5, 2020 at 11:18 AM Kyotaro Horiguchi
<horikyota(dot)ntt(at)gmail(dot)com> wrote:
>
> At Wed, 4 Nov 2020 22:49:57 +0900, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote in
> > On Wed, Nov 4, 2020 at 6:49 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> > >
> > > On Wed, Nov 4, 2020 at 2:25 PM Kyotaro Horiguchi
> > > <horikyota(dot)ntt(at)gmail(dot)com> wrote:
> > > >
> > > > Hello.
> > > >
> > > > While updating a patch, I noticed that the replication slot stats
> > > > patch (9868167500) put some somewhat doubious codes.
> > > >
> > > > In pgstat_recv_replslot, an assertion like the following exists:
> > > >
> > > > > idx = pgstat_replslot_index(msg->m_slotname, !msg->m_drop);
> > > > ..
> > > > > Assert(idx >= 0 && idx < max_replication_slots);
> > > >
> > > > But the idx should be 0..(max_replication_slots - 1).
> > > >
> > >
> > > Right.
> > >
> > > >
> > > > In the same function the following code assumes that the given "char
> > > > *name" has the length of NAMEDATALEN. It actually is, but that
> > > > assumption seems a bit bogus. I think it should use strlcpy instead.
> > > >
> > >
> > > Agreed.
> >
> > +1
> >
> > The commit uses memcpy in the same way in other places too, for
> > instance in pgstat_report_replslot_drop(). Should we fix all of them?
>
> Absolutely. the same is seen at several places. Please find the
> attached.
>
> As another issue, just replace memcpy with strlcpy makes compiler
> complain of type mismatch, as the first paramter to memcpy had an
> needless "&" operator. I removed it in this patch.
>
> (&msg.m_slotname is a "char (*)[NAMEDATALEN]", not a "char *".)
>

The patch looks good to me.

Regards,

--
Masahiko Sawada
EnterpriseDB: https://www.enterprisedb.com/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bharath Rupireddy 2020-11-05 04:20:11 Re: Log message for GSS connection is missing once connection authorization is successful.
Previous Message David Pirotte 2020-11-05 03:46:13 Re: Any objections to implementing LogicalDecodeMessageCB for pgoutput?