pg.ddx.io pgsql-bugs@postgresql.org mailing list archive
help / color / mirror / Atom feedPG16 walsender hangs in ResourceArrayEnlarge using pgoutput
7+ messages / 3 participants
[nested] [flat]
Commits from this thread:
2024-06-27 76fda61402 b8f953d8d7 3e53492aa7 Drop the temporary tuple slots allocated by pgoutput.
* PG16 walsender hangs in ResourceArrayEnlarge using pgoutput
@ 2024-06-25 07:52 Bowen Shi <zxwsbg12138@gmail.com>
2024-06-25 11:47 ` RE: PG16 walsender hangs in ResourceArrayEnlarge using pgoutput Zhijie Hou (Fujitsu) <houzj.fnst@fujitsu.com>
0 siblings, 1 reply; 7+ messages in thread
From: Bowen Shi @ 2024-06-25 07:52 UTC (permalink / raw)
To: PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Dears,
Recently I found a PG16 walsender hanging in the huge loop when I used the
subscription. This problem can reproduce with following steps:
1. create a partition table;
2. create a publication & subscription;
3. alter partition table with 'add column col varchar(10) NOT NULL DEFAULT
''::character varying' ;
4. insert/update 10000000 rows into partition table;
Then we can find the walsender process hang in the loop with stack:
#0 ResourceArrayAdd (resarr=0x2dfc048, value=140175392354560)
#1 ResourceArrayEnlarge (resarr=0x2dfc048)
#2 ResourceOwnerEnlargeTupleDescs (owner=0x2dfbf68)
#3 IncrTupleDescRefCount (tupdesc=0x7f7d2077b100)
#4 MakeTupleTableSlot (tupleDesc=0x7f7d2077b100, tts_ops=0xd237a0
<TTSOpsVirtual>)
#5 pgoutput_change (ctx=0x2eb1e68, txn=0x2edfec0, relation=0x7f7d2077e120,
change=0x2f35138)
#6 change_cb_wrapper (cache=0x2eb3e78, txn=0x2edfec0,
relation=0x7f7d2077e120, change=0x2f35138)
#7 ReorderBufferApplyChange (rb=0x2eb3e78, txn=0x2edfec0,
relation=0x7f7d2077e120, change=0x2f35138, streaming=false)
#8 ReorderBufferProcessTXN (rb=0x2eb3e78, txn=0x2edfec0,
commit_lsn=4675920936, snapshot_now=0x2ec82d0, command_id=0,
streaming=false)
#9 ReorderBufferReplay (txn=0x2edfec0, rb=0x2eb3e78, xid=758,
commit_lsn=4675920936, end_lsn=4675920984, commit_time=772615467516504,
origin_id=0, origin_lsn=0)
#10 ReorderBufferCommit (rb=0x2eb3e78, xid=758, commit_lsn=4675920936,
end_lsn=4675920984, commit_time=772615467516504, origin_id=0, origin_lsn=0)
#11 DecodeCommit (ctx=0x2eb1e68, buf=0x7ffe83c408f0, parsed=0x7ffe83c406f0,
xid=758, two_phase=false)
#12 xact_decode (ctx=0x2eb1e68, buf=0x7ffe83c408f0)
#13 LogicalDecodingProcessRecord (ctx=0x2eb1e68, record=0x2eb2200)
#14 XLogSendLogical ()
#15 WalSndLoop (send_data=0x95b183 <XLogSendLogical>)
#16 StartLogicalReplication (cmd=0x2e8fcd0)
#17 exec_replication_command (cmd_string=0x2dc3dc8 "START_REPLICATION SLOT
\"sub_t\" LOGICAL 0/0 (proto_version '4', origin 'any', publication_names
'\"pub_t\"')")
#18 PostgresMain (dbname=0x2dfa7c8 "tdts", username=0x2dfa7a8 "postgres")
#19 BackendRun (port=0x2dedd60)
#20 BackendStartup (port=0x2dedd60)
#21 ServerLoop ()
#22 PostmasterMain (argc=3, argv=0x2dbe920)
In pgoutput.c , I found some reasons:
1. In init_tuple_slot() function, we will build an attrmap when we publish
a partition table (entry->publish_as_relid != RelationGetRelid(relation))
and alter missing column into partition table with alter table statement;
2. In pgoutput_change(), we would convert the tuple if needed using
MakeTupleTableSlot() function;
3. When we update 30000000 rows,
MakeTupleTableSlot->PinTupleDesc->IncrTupleDescRefCount->ResourceOwnerEnlargeTupleDescs->ResourceArrayEnlarge,
we would call ResourceArrayAdd function too many times and cause the
problem.
Regards,
Bowen Shi
^ permalink raw reply [nested|flat] 7+ messages in thread
* RE: PG16 walsender hangs in ResourceArrayEnlarge using pgoutput
2024-06-25 07:52 PG16 walsender hangs in ResourceArrayEnlarge using pgoutput Bowen Shi <zxwsbg12138@gmail.com>
@ 2024-06-25 11:47 ` Zhijie Hou (Fujitsu) <houzj.fnst@fujitsu.com>
2024-06-26 05:05 ` Re: PG16 walsender hangs in ResourceArrayEnlarge using pgoutput Amit Kapila <amit.kapila16@gmail.com>
2024-06-26 06:30 ` Re: PG16 walsender hangs in ResourceArrayEnlarge using pgoutput Bowen Shi <zxwsbg12138@gmail.com>
0 siblings, 2 replies; 7+ messages in thread
From: Zhijie Hou (Fujitsu) @ 2024-06-25 11:47 UTC (permalink / raw)
To: Bowen Shi <zxwsbg12138@gmail.com>; +Cc: PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
On Tuesday, June 25, 2024 3:53 PM Bowen Shi <zxwsbg12138@gmail.com> wrote:
Hi,
> 1. create a partition table;
> 2. create a publication & subscription;
> 3. alter partition table with 'add column col varchar(10) NOT NULL DEFAULT ''::character varying' ;
> 4. insert/update 10000000 rows into partition table;
>
> Then we can find the walsender process hang in the loop with stack:
>
> #0 ResourceArrayAdd (resarr=0x2dfc048, value=140175392354560)
> #1 ResourceArrayEnlarge (resarr=0x2dfc048)
> #2 ResourceOwnerEnlargeTupleDescs (owner=0x2dfbf68)
> #3 IncrTupleDescRefCount (tupdesc=0x7f7d2077b100)
> #4 MakeTupleTableSlot (tupleDesc=0x7f7d2077b100, tts_ops=0xd237a0 <TTSOpsVirtual>)
> #5 pgoutput_change (ctx=0x2eb1e68, txn=0x2edfec0, relation=0x7f7d2077e120, change=0x2f35138)
> #6 change_cb_wrapper (cache=0x2eb3e78, txn=0x2edfec0, relation=0x7f7d2077e120, change=0x2f35138)
> #7 ReorderBufferApplyChange (rb=0x2eb3e78, txn=0x2edfec0, relation=0x7f7d2077e120, change=0x2f35138, streaming=false)
> #8 ReorderBufferProcessTXN (rb=0x2eb3e78, txn=0x2edfec0, commit_lsn=4675920936, snapshot_now=0x2ec82d0, command_id=0, streaming=false)
> #9 ReorderBufferReplay (txn=0x2edfec0, rb=0x2eb3e78, xid=758, commit_lsn=4675920936, end_lsn=4675920984, commit_time=772615467516504, origin_id=0, origin_lsn=0)
> #10 ReorderBufferCommit (rb=0x2eb3e78, xid=758, commit_lsn=4675920936, end_lsn=4675920984, commit_time=772615467516504, origin_id=0, origin_lsn=0)
> #11 DecodeCommit (ctx=0x2eb1e68, buf=0x7ffe83c408f0, parsed=0x7ffe83c406f0, xid=758, two_phase=false)
> #12 xact_decode (ctx=0x2eb1e68, buf=0x7ffe83c408f0)
> #13 LogicalDecodingProcessRecord (ctx=0x2eb1e68, record=0x2eb2200)
> #14 XLogSendLogical ()
> #15 WalSndLoop (send_data=0x95b183 <XLogSendLogical>)
> #16 StartLogicalReplication (cmd=0x2e8fcd0)
> #17 exec_replication_command (cmd_string=0x2dc3dc8 "START_REPLICATION SLOT \"sub_t\" LOGICAL 0/0 (proto_version '4', origin 'any', publication_names '\"pub_t\"')")
> #18 PostgresMain (dbname=0x2dfa7c8 "tdts", username=0x2dfa7a8 "postgres")
> #19 BackendRun (port=0x2dedd60)
> #20 BackendStartup (port=0x2dedd60)
> #21 ServerLoop ()
> #22 PostmasterMain (argc=3, argv=0x2dbe920)
>
> In pgoutput.c , I found some reasons:
> 1. In init_tuple_slot() function, we will build an attrmap when we publish a partition table (entry->publish_as_relid != RelationGetRelid(relation)) and alter missing column into partition table with alter table statement;
> 2. In pgoutput_change(), we would convert the tuple if needed using MakeTupleTableSlot() function;
> 3. When we update 30000000 rows, MakeTupleTableSlot->PinTupleDesc->IncrTupleDescRefCount->ResourceOwnerEnlargeTupleDescs->ResourceArrayEnlarge, we would call ResourceArrayAdd function too many times and cause the problem.
Thanks for reporting and analyzing the issue !
You analysis looks good to me, I think I missed to drop the newly created
slot when changing the logic to support row filter. Here is a small patch
to drop the slots in each cycle, it can fix the issue on my machine.
IIUC, the issue exists from PG15~HEAD. The current patch can apply
on PG16~HEAD, If it looks ok, I will test and prepare the patch for the
other branch.
Best Regards,
Hou zj
Attachments:
0001-Drop-the-tuple-slot-when-no-longer-needed.patch (application/octet-stream, 1.3K) download
From 9a5cee68d380e18615a784a20ba7779cffc99571 Mon Sep 17 00:00:00 2001
From: Hou Zhijie <houzj.fnst@cn.fujitsu.com>
Date: Tue, 25 Jun 2024 19:30:07 +0800
Subject: [PATCH] Drop the tuple slot when no longer needed
In pgoutput, when converting the child table's tuple format to match the
parent table's, we temporarily create a new slot to store the converted
tuple. However, we missed to drop such temp slots, leading to resource
accumulation and causing the walsender to hang.
This commit fix the issue by dropping the temp slots in each cycle.
---
src/backend/replication/pgoutput/pgoutput.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/src/backend/replication/pgoutput/pgoutput.c b/src/backend/replication/pgoutput/pgoutput.c
index d2b35cfb96..b8fa90e09b 100644
--- a/src/backend/replication/pgoutput/pgoutput.c
+++ b/src/backend/replication/pgoutput/pgoutput.c
@@ -1554,6 +1554,19 @@ cleanup:
ancestor = NULL;
}
+ /*
+ * If the tuple was converted, drop the new slot that was used to
+ * store the converted tuple.
+ */
+ if (relentry->attrmap)
+ {
+ if (old_slot)
+ ExecDropSingleTupleTableSlot(old_slot);
+
+ if (new_slot)
+ ExecDropSingleTupleTableSlot(new_slot);
+ }
+
MemoryContextSwitchTo(old);
MemoryContextReset(data->context);
}
--
2.30.0.windows.2
* Re: PG16 walsender hangs in ResourceArrayEnlarge using pgoutput
2024-06-25 07:52 PG16 walsender hangs in ResourceArrayEnlarge using pgoutput Bowen Shi <zxwsbg12138@gmail.com>
2024-06-25 11:47 ` RE: PG16 walsender hangs in ResourceArrayEnlarge using pgoutput Zhijie Hou (Fujitsu) <houzj.fnst@fujitsu.com>
@ 2024-06-26 05:05 ` Amit Kapila <amit.kapila16@gmail.com>
2024-06-26 05:25 ` Re: PG16 walsender hangs in ResourceArrayEnlarge using pgoutput Amit Kapila <amit.kapila16@gmail.com>
1 sibling, 1 reply; 7+ messages in thread
From: Amit Kapila @ 2024-06-26 05:05 UTC (permalink / raw)
To: Zhijie Hou (Fujitsu) <houzj.fnst@fujitsu.com>; +Cc: Bowen Shi <zxwsbg12138@gmail.com>; PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
On Tue, Jun 25, 2024 at 5:17 PM Zhijie Hou (Fujitsu)
<houzj.fnst@fujitsu.com> wrote:
>
> On Tuesday, June 25, 2024 3:53 PM Bowen Shi <zxwsbg12138@gmail.com> wrote:
>
> Thanks for reporting and analyzing the issue !
>
> You analysis looks good to me, I think I missed to drop the newly created
> slot when changing the logic to support row filter. Here is a small patch
> to drop the slots in each cycle, it can fix the issue on my machine.
>
> IIUC, the issue exists from PG15~HEAD. The current patch can apply
> on PG16~HEAD, If it looks ok, I will test and prepare the patch for the
> other branch.
>
IIUC, the relevant code was added in commit
da324d6cd45bbbcc1682cc2fcbc4f575281916af. This is a PG16 commit, so
how can the problem occur in PG15?
BTW, can we think of a resource owner for managing pgoutput resources
similar to the memory context we have in PGOutputData? This will avoid
allocating the resources in Xact or other resource owners. This will
make resource management local to pgoutput similar to what we have for
memory context in PGOutputData. I suggest having a separate resource
owner only for the HEAD branch (which will be PG18).
--
With Regards,
Amit Kapila.
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: PG16 walsender hangs in ResourceArrayEnlarge using pgoutput
2024-06-25 07:52 PG16 walsender hangs in ResourceArrayEnlarge using pgoutput Bowen Shi <zxwsbg12138@gmail.com>
2024-06-25 11:47 ` RE: PG16 walsender hangs in ResourceArrayEnlarge using pgoutput Zhijie Hou (Fujitsu) <houzj.fnst@fujitsu.com>
2024-06-26 05:05 ` Re: PG16 walsender hangs in ResourceArrayEnlarge using pgoutput Amit Kapila <amit.kapila16@gmail.com>
@ 2024-06-26 05:25 ` Amit Kapila <amit.kapila16@gmail.com>
2024-06-27 03:31 ` RE: PG16 walsender hangs in ResourceArrayEnlarge using pgoutput Zhijie Hou (Fujitsu) <houzj.fnst@fujitsu.com>
0 siblings, 1 reply; 7+ messages in thread
From: Amit Kapila @ 2024-06-26 05:25 UTC (permalink / raw)
To: Zhijie Hou (Fujitsu) <houzj.fnst@fujitsu.com>; +Cc: Bowen Shi <zxwsbg12138@gmail.com>; PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
On Wed, Jun 26, 2024 at 10:35 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Tue, Jun 25, 2024 at 5:17 PM Zhijie Hou (Fujitsu)
> <houzj.fnst@fujitsu.com> wrote:
> >
> > On Tuesday, June 25, 2024 3:53 PM Bowen Shi <zxwsbg12138@gmail.com> wrote:
> >
> > Thanks for reporting and analyzing the issue !
> >
> > You analysis looks good to me, I think I missed to drop the newly created
> > slot when changing the logic to support row filter. Here is a small patch
> > to drop the slots in each cycle, it can fix the issue on my machine.
> >
> > IIUC, the issue exists from PG15~HEAD. The current patch can apply
> > on PG16~HEAD, If it looks ok, I will test and prepare the patch for the
> > other branch.
> >
>
> IIUC, the relevant code was added in commit
> da324d6cd45bbbcc1682cc2fcbc4f575281916af. This is a PG16 commit, so
> how can the problem occur in PG15?
>
I see that originally the slot allocation code was introduced in
commit 52e4f0cd472d39d07732b99559989ea3b615be78 but later the code
refactored in da324d6cd45bbbcc1682cc2fcbc4f575281916af. So, I agree
that we must also fix this in PG15.
--
With Regards,
Amit Kapila.
^ permalink raw reply [nested|flat] 7+ messages in thread
* RE: PG16 walsender hangs in ResourceArrayEnlarge using pgoutput
2024-06-25 07:52 PG16 walsender hangs in ResourceArrayEnlarge using pgoutput Bowen Shi <zxwsbg12138@gmail.com>
2024-06-25 11:47 ` RE: PG16 walsender hangs in ResourceArrayEnlarge using pgoutput Zhijie Hou (Fujitsu) <houzj.fnst@fujitsu.com>
2024-06-26 05:05 ` Re: PG16 walsender hangs in ResourceArrayEnlarge using pgoutput Amit Kapila <amit.kapila16@gmail.com>
2024-06-26 05:25 ` Re: PG16 walsender hangs in ResourceArrayEnlarge using pgoutput Amit Kapila <amit.kapila16@gmail.com>
@ 2024-06-27 03:31 ` Zhijie Hou (Fujitsu) <houzj.fnst@fujitsu.com>
2024-06-27 12:23 ` Re: PG16 walsender hangs in ResourceArrayEnlarge using pgoutput Amit Kapila <amit.kapila16@gmail.com>
0 siblings, 1 reply; 7+ messages in thread
From: Zhijie Hou (Fujitsu) @ 2024-06-27 03:31 UTC (permalink / raw)
To: Amit Kapila <amit.kapila16@gmail.com>; +Cc: Bowen Shi <zxwsbg12138@gmail.com>; PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
On Wednesday, June 26, 2024 1:25 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Wed, Jun 26, 2024 at 10:35 AM Amit Kapila <amit.kapila16@gmail.com>
> wrote:
> >
> > On Tue, Jun 25, 2024 at 5:17 PM Zhijie Hou (Fujitsu)
> > <houzj.fnst@fujitsu.com> wrote:
> > >
> > > On Tuesday, June 25, 2024 3:53 PM Bowen Shi
> <zxwsbg12138@gmail.com> wrote:
> > >
> > > Thanks for reporting and analyzing the issue !
> > >
> > > You analysis looks good to me, I think I missed to drop the newly
> > > created slot when changing the logic to support row filter. Here is
> > > a small patch to drop the slots in each cycle, it can fix the issue on my
> machine.
> > >
> > > IIUC, the issue exists from PG15~HEAD. The current patch can apply
> > > on PG16~HEAD, If it looks ok, I will test and prepare the patch for
> > > the other branch.
> > >
> >
> > IIUC, the relevant code was added in commit
> > da324d6cd45bbbcc1682cc2fcbc4f575281916af. This is a PG16 commit, so
> > how can the problem occur in PG15?
> >
>
> I see that originally the slot allocation code was introduced in commit
> 52e4f0cd472d39d07732b99559989ea3b615be78 but later the code refactored in
> da324d6cd45bbbcc1682cc2fcbc4f575281916af. So, I agree that we must also
> fix this in PG15.
Thanks for confirming! Here are the patches for all branches.
I am researching the comment for resource owner and will reply later.
Best Regards,
Hou zj
Attachments: download all (2 files, .tar.gz)
v2-PG15-0001-Drop-the-tuple-slot-when-no-longer-needed.patch (application/octet-stream, 1.4K) download
From 354bd884059d8a7b0da1c194482ab84cfd5fd9f9 Mon Sep 17 00:00:00 2001
From: Hou Zhijie <houzj.fnst@cn.fujitsu.com>
Date: Thu, 27 Jun 2024 10:57:34 +0800
Subject: [PATCH v2] Drop the tuple slot when no longer needed
In pgoutput, when converting the child table's tuple format to match the
parent table's, we temporarily create a new slot to store the converted
tuple. However, we missed to drop such temp slots, leading to resource
accumulation and causing the walsender to hang.
This commit fix the issue by dropping the temp slots in each cycle.
---
src/backend/replication/pgoutput/pgoutput.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/src/backend/replication/pgoutput/pgoutput.c b/src/backend/replication/pgoutput/pgoutput.c
index 5fc0defec3..6bd8e95356 100644
--- a/src/backend/replication/pgoutput/pgoutput.c
+++ b/src/backend/replication/pgoutput/pgoutput.c
@@ -1587,6 +1587,19 @@ pgoutput_change(LogicalDecodingContext *ctx, ReorderBufferTXN *txn,
ancestor = NULL;
}
+ /*
+ * If the tuple was converted, drop the new slot that was used to store
+ * the converted tuple.
+ */
+ if (relentry->attrmap)
+ {
+ if (old_slot)
+ ExecDropSingleTupleTableSlot(old_slot);
+
+ if (new_slot)
+ ExecDropSingleTupleTableSlot(new_slot);
+ }
+
/* Cleanup */
MemoryContextSwitchTo(old);
MemoryContextReset(data->context);
--
2.30.0.windows.2
v2-PG16-HEAD-0001-Drop-the-tuple-slot-when-no-longer-needed.patch (application/octet-stream, 1.3K) download
From a69b61303ed9d3897e938070ce6b974d5d9b3e95 Mon Sep 17 00:00:00 2001
From: Hou Zhijie <houzj.fnst@cn.fujitsu.com>
Date: Tue, 25 Jun 2024 19:30:07 +0800
Subject: [PATCH v2] Drop the tuple slot when no longer needed
In pgoutput, when converting the child table's tuple format to match the
parent table's, we temporarily create a new slot to store the converted
tuple. However, we missed to drop such temp slots, leading to resource
accumulation and causing the walsender to hang.
This commit fix the issue by dropping the temp slots in each cycle.
---
src/backend/replication/pgoutput/pgoutput.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/src/backend/replication/pgoutput/pgoutput.c b/src/backend/replication/pgoutput/pgoutput.c
index d2b35cfb96..490e0af014 100644
--- a/src/backend/replication/pgoutput/pgoutput.c
+++ b/src/backend/replication/pgoutput/pgoutput.c
@@ -1554,6 +1554,19 @@ cleanup:
ancestor = NULL;
}
+ /*
+ * If the tuple was converted, drop the new slot that was used to store
+ * the converted tuple.
+ */
+ if (relentry->attrmap)
+ {
+ if (old_slot)
+ ExecDropSingleTupleTableSlot(old_slot);
+
+ if (new_slot)
+ ExecDropSingleTupleTableSlot(new_slot);
+ }
+
MemoryContextSwitchTo(old);
MemoryContextReset(data->context);
}
--
2.30.0.windows.2
* Re: PG16 walsender hangs in ResourceArrayEnlarge using pgoutput
2024-06-25 07:52 PG16 walsender hangs in ResourceArrayEnlarge using pgoutput Bowen Shi <zxwsbg12138@gmail.com>
2024-06-25 11:47 ` RE: PG16 walsender hangs in ResourceArrayEnlarge using pgoutput Zhijie Hou (Fujitsu) <houzj.fnst@fujitsu.com>
2024-06-26 05:05 ` Re: PG16 walsender hangs in ResourceArrayEnlarge using pgoutput Amit Kapila <amit.kapila16@gmail.com>
2024-06-26 05:25 ` Re: PG16 walsender hangs in ResourceArrayEnlarge using pgoutput Amit Kapila <amit.kapila16@gmail.com>
2024-06-27 03:31 ` RE: PG16 walsender hangs in ResourceArrayEnlarge using pgoutput Zhijie Hou (Fujitsu) <houzj.fnst@fujitsu.com>
@ 2024-06-27 12:23 ` Amit Kapila <amit.kapila16@gmail.com>
0 siblings, 0 replies; 7+ messages in thread
From: Amit Kapila @ 2024-06-27 12:23 UTC (permalink / raw)
To: Zhijie Hou (Fujitsu) <houzj.fnst@fujitsu.com>; +Cc: Bowen Shi <zxwsbg12138@gmail.com>; PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
On Thu, Jun 27, 2024 at 9:01 AM Zhijie Hou (Fujitsu)
<houzj.fnst@fujitsu.com> wrote:
>
> On Wednesday, June 26, 2024 1:25 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> > >
> > > IIUC, the relevant code was added in commit
> > > da324d6cd45bbbcc1682cc2fcbc4f575281916af. This is a PG16 commit, so
> > > how can the problem occur in PG15?
> > >
> >
> > I see that originally the slot allocation code was introduced in commit
> > 52e4f0cd472d39d07732b99559989ea3b615be78 but later the code refactored in
> > da324d6cd45bbbcc1682cc2fcbc4f575281916af. So, I agree that we must also
> > fix this in PG15.
>
> Thanks for confirming! Here are the patches for all branches.
>
Pushed.
--
With Regards,
Amit Kapila.
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: PG16 walsender hangs in ResourceArrayEnlarge using pgoutput
2024-06-25 07:52 PG16 walsender hangs in ResourceArrayEnlarge using pgoutput Bowen Shi <zxwsbg12138@gmail.com>
2024-06-25 11:47 ` RE: PG16 walsender hangs in ResourceArrayEnlarge using pgoutput Zhijie Hou (Fujitsu) <houzj.fnst@fujitsu.com>
@ 2024-06-26 06:30 ` Bowen Shi <zxwsbg12138@gmail.com>
1 sibling, 0 replies; 7+ messages in thread
From: Bowen Shi @ 2024-06-26 06:30 UTC (permalink / raw)
To: Zhijie Hou (Fujitsu) <houzj.fnst@fujitsu.com>; +Cc: PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Hi,
On Tue, Jun 25, 2024 at 7:47 PM Zhijie Hou (Fujitsu) <houzj.fnst@fujitsu.com>
wrote:
> You analysis looks good to me, I think I missed to drop the newly created
> slot when changing the logic to support row filter. Here is a small patch
> to drop the slots in each cycle, it can fix the issue on my machine.
>
> IIUC, the issue exists from PG15~HEAD. The current patch can apply
> on PG16~HEAD, If it looks ok, I will test and prepare the patch for the
> other branch.
This patch looks good to me. I tested again and didn't reproduce the
problem.
Regards,
Bowen Shi
^ permalink raw reply [nested|flat] 7+ messages in thread
end of thread, other threads:[~2024-06-27 12:23 UTC | newest]
Thread overview: 7+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2024-06-25 07:52 PG16 walsender hangs in ResourceArrayEnlarge using pgoutput Bowen Shi <zxwsbg12138@gmail.com>
2024-06-25 11:47 ` Zhijie Hou (Fujitsu) <houzj.fnst@fujitsu.com>
2024-06-26 05:05 ` Amit Kapila <amit.kapila16@gmail.com>
2024-06-26 05:25 ` Amit Kapila <amit.kapila16@gmail.com>
2024-06-27 03:31 ` Zhijie Hou (Fujitsu) <houzj.fnst@fujitsu.com>
2024-06-27 12:23 ` Amit Kapila <amit.kapila16@gmail.com>
2024-06-26 06:30 ` Bowen Shi <zxwsbg12138@gmail.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox