Re: Some doubious code in pgstat.c - Mailing list pgsql-hackers

From Masahiko Sawada
Subject Re: Some doubious code in pgstat.c
Date
Msg-id CAD21AoCyNKkWdbTpoVAnNR7fxaiEp0rj4j6DinMYP2ER+23How@mail.gmail.com
Whole thread Raw
In response to Re: Some doubious code in pgstat.c  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: Some doubious code in pgstat.c  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
List pgsql-hackers
On Wed, Nov 4, 2020 at 6:49 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Wed, Nov 4, 2020 at 2:25 PM Kyotaro Horiguchi
> <horikyota.ntt@gmail.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?

Regards,

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



pgsql-hackers by date:

Previous
From: Daniel Gustafsson
Date:
Subject: Re: Support for NSS as a libpq TLS backend
Next
From: Tomas Vondra
Date:
Subject: Re: PANIC: could not fsync file "pg_multixact/..." since commit dee663f7843