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
- v2-0001-Fix-memory-overrun-of-pg_stat_get_slru.patch (text/x-patch)
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
-
Fix memory overrun when querying pg_stat_slru
- a691a229831a 13.6 landed
- 5f81a480d537 14.2 landed
- a45ed975c58f 15.0 landed