Re: Some doubious code in pgstat.c

From: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Kyotaro Horiguchi <horikyota(dot)ntt(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-04 13:49:57
Message-ID: CAD21AoCyNKkWdbTpoVAnNR7fxaiEp0rj4j6DinMYP2ER+23How@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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?

Regards,

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2020-11-04 13:50:30 Re: PANIC: could not fsync file "pg_multixact/..." since commit dee663f7843
Previous Message Daniel Gustafsson 2020-11-04 13:14:12 Re: Support for NSS as a libpq TLS backend