Re: [PATCH] Fix memory corruption in pg_shdepend.c - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [PATCH] Fix memory corruption in pg_shdepend.c
Date
Msg-id 2704180.1634909920@sss.pgh.pa.us
Whole thread Raw
In response to Re: [PATCH] Fix memory corruption in pg_shdepend.c  (Michael Paquier <michael@paquier.xyz>)
Responses Re: [PATCH] Fix memory corruption in pg_shdepend.c  (Daniel Gustafsson <daniel@yesql.se>)
List pgsql-hackers
Michael Paquier <michael@paquier.xyz> writes:
> On Fri, Oct 22, 2021 at 10:48:57AM +0300, Aleksander Alekseev wrote:
>> ... where the slot is allocated with palloc0. The assumption that
>> MakeSingleTupleTableSlot() returns valid TupleTableSlot* with zeroed
>> tts_isnull[] seems reasonable, no?

> Yes, I don't see any need to do something more here.

That assumption is exactly what I'm objecting to.  I don't think
we make it in other places, and I don't like making it here.
(By "here" I mean all of e3931d0, because it made the same omission
in several places.)

The primary reason why I think it's a bad idea is that only one
path in MakeSingleTupleTableSlot provides a pre-zeroed tts_isnull
array --- if you don't supply a tuple descriptor at creation,
the assumption falls down.  So even if this coding technique is
safe where it is, it is a hazard for anyone copying the code into
some other context.

I might be happier if we tried to guarantee that *every* way of
creating a slot will end with a pre-zeroed isnull array, and then
got rid of any thereby-duplicative memsets.  But that would be
a lot more invasive than just making these places get in step.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Amul Sul
Date:
Subject: Re: prevent immature WAL streaming
Next
From: Aleksander Alekseev
Date:
Subject: Refactoring: join MakeSingleTupleTableSlot() and MakeTupleTableSlot()