Re: pg_dump: Fix dangling pointer in EndCompressorZstd()

> On 17 Apr 2025, at 01:12, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Michael Paquier <michael(at)paquier(dot)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.

Right, it has no similar test as the state in private_data is needed for both
read and write whereas gzip for example only need it for write (deflate).
Pushed as it improves code hygiene.

--
Daniel Gustafsson