Re: Use stack-allocated StringInfoData - Mailing list pgsql-hackers

From David Rowley
Subject Re: Use stack-allocated StringInfoData
Date
Msg-id CAApHDvrZnM28wa2VY58cvtY0y9XbMhKJH4m=ga3c1wfsx=MF4Q@mail.gmail.com
Whole thread Raw
In response to Re: Use stack-allocated StringInfoData  (Mats Kindahl <mats.kindahl@gmail.com>)
Responses Re: Use stack-allocated StringInfoData
Re: Use stack-allocated StringInfoData
Re: Use stack-allocated StringInfoData
List pgsql-hackers
On Tue, 4 Nov 2025 at 21:25, Mats Kindahl <mats.kindahl@gmail.com> wrote:
> Here is an updated patch that I checked manually for unnecessary
> whitespace changes.

Thanks for updating the patch.

> There is one such case affected by this patch, and there the buffer
> pointer is copied to another variable and then returned. This can
> probably be improved by just returning the buffer pointer directly
> without intermediate assignment to a variable, but I avoided this to
> make reviewing the code easier. It is easy to add this change either now
> or later and should not affect the generated code except at very low
> optimization levels.

Yeah, I think you must mean in build_backup_content(). I noticed that too.

> I also added fixes manually inside check_publications_origin_tables,
> check_publications, and fetch_relation_list. In
> check_publication_origin_table three StringInfo was dynamically
> allocated but not released after. In check_publications and
> fetch_relation_list there were extra cases of using a dynamically
> allocated StringInfo that was not necessary.

It's not your fault, but check_publications_origin_tables() looks like
a mess. It seems like excessive use of additional code just to avoid
two separate ereport() calls. Might be worth a follow-up patch to
clean that up.

The patch looks good to me. The only thing I'd adjust is to get rid of
the "data" variable from build_backup_content(), which I think you
mentioned above. I can take care of that one.

I can push this tomorrow morning UTC+13. I'll leave it til then in
case anyone else has any comments.

David



pgsql-hackers by date:

Previous
From: Alexander Korotkov
Date:
Subject: Re: Newly created replication slot may be invalidated by checkpoint
Next
From: Peter Eisentraut
Date:
Subject: inconsistent tableoid handling in COPY WHERE clause