On Wed, Nov 20, 2024 at 10:41:50AM +, by Yang wrote:
> I apologize for the obvious error in the previous patch. I have corrected it
> in the new patch(v3) and pass the regression testing.
It took me quite a bit of time to evaluate the amount of the damage,
and indeed sysbench has been quite go
> You should be more careful with the amount of tests you are doing
> here. This fails while waiting for some changes to be streamed when
> creating a subscription:
> cd src/test/subscription/ && PROVE_TESTS=t/017_stream_ddl.pl make check
I apologize for the obvious error in the previous patch. I
On Tue, Nov 19, 2024 at 07:08:26AM +, by Yang wrote:
> I have verifed that this patch works for REL_[15-17]_STABLE and master.
> The memory consumption of "logical replication cache context" remains
> consistently at 112 MB during the benchmark mentioned above.
You should be more careful with
> By the way, if possible, could you send an updated version of the
> patch to show what you have in mind?
Yeah, here is the new patch:
I have verifed that this patch works for REL_[15-17]_STABLE and master.
The memory consumption of "logical replication cache context" remains
consistently at 112
On Mon, Nov 18, 2024 at 04:58:38PM +0900, Michael Paquier wrote:
> On Mon, Nov 18, 2024 at 07:00:57AM +, by Yang wrote:
>> By the way, this issue is introduced in 52e4f0cd472d39d. Therefore, we may
>> need
>> to backport the patch to v15.
>
> Yes. Note that nothing can happen on stable branc
On Mon, Nov 18, 2024 at 07:00:57AM +, by Yang wrote:
> By the way, this issue is introduced in 52e4f0cd472d39d. Therefore, we may
> need
> to backport the patch to v15.
Yes. Note that nothing can happen on stable branches for a few days
as a release is planned for this week. See here:
https
> Here, after freeing the tupledesc, the ExecDropSingleTupleTableSlot will still
> access the freed tupledesc->tdrefcount which is an illegal memory access.
Yes, I overlooked that.
> I think we can do something like below instead:
>
> + TupleDesc desc =
> entry->old_s
On Mon, Nov 18, 2024 at 02:53:52AM +, Zhijie Hou (Fujitsu) wrote:
> But I think there is an issue in the attached patch:
>
> + FreeTupleDesc(entry->old_slot->tts_tupleDescriptor);
> ExecDropSingleTupleTableSlot(entry->old_slot);
>
> Here, after freein
On Saturday, November 16, 2024 4:37 PM by Yang wrote:
> I recently noticed a unusually large memory consumption in pgoutput where
> "RelationSyncCache" is maintaining approximately 3 GB of memory while
> handling 15,000 tables.
>
> Upon investigating the cause, I found that "tts_tupleDescriptor
