Re: pg_dump: Fix dangling pointer in EndCompressorZstd() - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg_dump: Fix dangling pointer in EndCompressorZstd()
Date
Msg-id 2085462.1744845172@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_dump: Fix dangling pointer in EndCompressorZstd()  (Michael Paquier <michael@paquier.xyz>)
Responses Re: pg_dump: Fix dangling pointer in EndCompressorZstd()
List pgsql-hackers
Michael Paquier <michael@paquier.xyz> writes:
> On Wed, Apr 16, 2025 at 04:19:02PM +0200, Daniel Gustafsson wrote:
>> Agreed, while it's perfectly safe today the end method should not make
>> assumptions about the use of the private_data pointer upon return and should
>> leave it set to NULL.

> Indeed.  I was just looking at applying what Alexander has sent
> because what EndCompressorZstd() not doing what the other methods do
> makes no sense.  Perhaps you are already on it, Daniel?

I think the actual reason for the difference is that the methods that
are taking care to zero the pointer do so because they test the
pointer themselves.  For instance in EndCompressorGzip, the test is
needed because perhaps no data was sent so the struct never got made.
It incidentally offers protection against a double call of that
function, but I don't think that was the intended reason.

I don't have any big objection to zeroing the pointer in
EndCompressorZstd, but I think the claim that it's precisely
analogous to the other EndCompressor methods is faulty,
because it has no similar test.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Jacob Champion
Date:
Subject: Re: jsonapi: scary new warnings with LTO enabled
Next
From: Noah Misch
Date:
Subject: Re: pipelining in psql, commit 41625ab