Fix a typo of func DecodeInsert()

[Yongtao Huang]

Hi all,
I think the comment above the function DecodeInsert()
in src/backend/replication/logical/decode.c should be
+ * *Inserts *can contain the new tuple.
, rather than
- * *Deletes *can contain the new tuple.

Please correct me if I'm wrong, thanks a lot.


0001-Fix-a-typo-of-func-DecodeInsert.patch
Description: Binary data

Re: Fix a typo of func DecodeInsert()

[Yongtao Huang]

Thank you. I prefer to keep the comments of these three functions
*DecodeInsert()*,  *DecodeUpdate()*, and *DecodeDelete()* aligned.
```
/*
 * Parse XLOG_HEAP_INSERT (not MULTI_INSERT!) records into tuplebufs.
 *
 * Inserts can contain the new tuple.
 */
static void
DecodeInsert(LogicalDecodingContext *ctx, XLogRecordBuffer *buf)

/*
 * Parse XLOG_HEAP_UPDATE and XLOG_HEAP_HOT_UPDATE, which have the same
layout
 * in the record, from wal into proper tuplebufs.
 *
 * Updates can possibly contain a new tuple and the old primary key.
 */
static void
DecodeUpdate(LogicalDecodingContext *ctx, XLogRecordBuffer *buf)

/*
 * Parse XLOG_HEAP_DELETE from wal into proper tuplebufs.
 *
 * Deletes can possibly contain the old primary key.
 */
static void
DecodeDelete(LogicalDecodingContext *ctx, XLogRecordBuffer *buf)

```

Best wishes

Yongtao Huang


Richard Guo  于2024年1月17日周三 09:10写道：

>
> On Wed, Jan 17, 2024 at 8:47 AM Yongtao Huang 
> wrote:
>
>> Hi all,
>> I think the comment above the function DecodeInsert()
>> in src/backend/replication/logical/decode.c should be
>> + * *Inserts *can contain the new tuple.
>> , rather than
>> - * *Deletes *can contain the new tuple.
>>
>
> Nice catch.  +1.
>
> I kind of wonder if it would be clearer to state that "XLOG_HEAP_INSERT
> can contain the new tuple", in order to differentiate it from
> XLOG_HEAP2_MULTI_INSERT.
>
> Thanks
> Richard
>

Fix incorrect format placeholders in walreceiver.c

[Yongtao Huang]

Hi all,

I think the correct placeholder for var *startoff* should be *%d*.
Thanks for your time.

Best

Yongtao Huang


0001-Fix-incorrect-format-placeholders-in-walreceiver.c.patch
Description: Binary data

Optimize duplicate code and fix memory leak in function fetch_remote_table_info()

[Yongtao Huang]

This patch fixes two things in the function fetch_remote_table_info().

(1) *pfree(pub_names.data)* to avoid potential memory leaks.
(2) 2 pieces of code can do the same work,

``` C
foreach(lc, MySubscription->publications)
{
if (foreach_current_index(lc) > 0)
appendStringInfoString(&pub_names, ", ");
appendStringInfoString(&pub_names,
quote_literal_cstr(strVal(lfirst(lc;
}
```
and
``` C
foreach_node(String, pubstr, MySubscription->publications)
{
char   *pubname = strVal(pubstr);

if (foreach_current_index(pubstr) > 0)
appendStringInfoString(&pub_names, ", ");

appendStringInfoString(&pub_names, quote_literal_cstr(pubname));
}
```
I wanna integrate them into one function `make_pubname_list()` to make the
code neater.

Thanks for your time.

Regards

Yongtao Huang


0001-Optimize-duplicate-code-and-fix-memory-leak-in-table.patch
Description: Binary data

Re: Optimize duplicate code and fix memory leak in function fetch_remote_table_info()

[Yongtao Huang]

Thanks for your review.

(1)  I think *pfree(pub_names.data)* is necessary.
(2)  Agree with you. Considering that the new function is only called
twice, not encapsulating it into a function is not a huge problem.

Best wishes

Yongtao Huang

Michael Paquier  于2024年1月20日周六 11:13写道：

> On Fri, Jan 19, 2024 at 10:42:46PM +0800, Yongtao Huang wrote:
> > This patch fixes two things in the function fetch_remote_table_info().
> >
> > (1) *pfree(pub_names.data)* to avoid potential memory leaks.
>
> True that this code puts some effort in cleaning up the memory used
> locally.
>
> > (2) 2 pieces of code can do the same work,
> > ```
> > I wanna integrate them into one function `make_pubname_list()` to make
> the
> > code neater.
>
> It does not strike me as a huge problem to let the code be as it is on
> HEAD when building the lists, FWIW, as we are talking about two places
> and there is clarity in keeping the code as it is.
> --
> Michael
>


0001-Fix-potential-memory-leak-in-tablesync.c.patch
Description: Binary data

Re: Optimize duplicate code and fix memory leak in function fetch_remote_table_info()

[Yongtao Huang]

Hi，

>  So whatever it leaks will be released at the transaction end.

I learned it. thank you very much for your explanation.

Regards,
Yongtao Huang

Tom Lane  于2024年1月20日周六 12:34写道：

> Yongtao Huang  writes:
> > (1)  I think *pfree(pub_names.data)* is necessary.
>
> Really?
>
> It looks to me like copy_table, and thence fetch_remote_table_info,
> is called once within a transaction.  So whatever it leaks will be
> released at transaction end.  This is a good thing, because it's
> messy enough that I seriously doubt that there aren't other leaks
> in it, or that it'd be practical to expect that it can be made
> to never leak anything.
>
> If anything, I'd be inclined to remove the random pfree's that
> are in it now.  It's unlikely that they constitute a net win
> compared to allowing memory context reset to clean things up.
>
> regards, tom lane
>

Fix some typos

[Yongtao Huang]

Hi all,

As the title said, just fix some typos.

Regards

Yongtao Huang


0001-Fix-some-typos.patch
Description: Binary data