Re: BUG #17280: global-buffer-overflow on select from pg_stat_slru

Kyotaro Horiguchi <horikyota.ntt@gmail.com>

From: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
To: michael@paquier.xyz
Cc: a.kozhemyakin@postgrespro.ru, pgsql-bugs@lists.postgresql.org
Date: 2021-11-11T03:19:09Z
Lists: pgsql-bugs

Attachments

At Thu, 11 Nov 2021 11:52:27 +0900, Michael Paquier <michael@paquier.xyz> wrote in 
> On Thu, Nov 11, 2021 at 10:39:23AM +0900, Kyotaro Horiguchi wrote:
> > The loop is designed not to directly rely on SRLU_NUM_ELEMENTS so if
> > we honor that design, we would take the first or the third way. The
> > first way is smallest but I prefer the third way as it is
> > straightforward as such kind of loops.  The attached is that for the
> > master.
> > 
> > The code was introduced at 13 and the attached applies to the versions
> > back to 13.
> 
> Or it would be easier for the reader to assign stat after checking for
> the result of pgstat_slru_name(), no?  I am not much a fan of this
> code style that uses a counter, FWIW, but at the same time
> SLRU_NUM_ELEMENTS is local to pgstat.c, so..

I'm not sure which is easier to read, but it might be a bit hard since
the conditino term in not mention counter itself. I don't object to
that way.  And, yes SLRU_NUM_ELEMENTS cannot be used here:p

The attached is the first way in the choices.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center

Commits

  1. Fix memory overrun when querying pg_stat_slru