RE: Replica Identity check of partition table on subscriber
От | houzj.fnst@fujitsu.com |
---|---|
Тема | RE: Replica Identity check of partition table on subscriber |
Дата | |
Msg-id | OS0PR01MB5716CC025E36CC4652170FBA94B29@OS0PR01MB5716.jpnprd01.prod.outlook.com обсуждение исходный текст |
Ответ на | Re: Replica Identity check of partition table on subscriber (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: Replica Identity check of partition table on subscriber
|
Список | pgsql-hackers |
On Wednesday, June 22, 2022 7:06 PM Amit Kapila <amit.kapila16@gmail.com> wrote: > > On Wed, Jun 22, 2022 at 10:09 AM Amit Langote <amitlangote09@gmail.com> > wrote: > > > > On Wed, Jun 22, 2022 at 12:02 PM houzj.fnst@fujitsu.com > > <houzj.fnst@fujitsu.com> wrote: > > > Since the patch has been committed. Attach the last patch to fix the > memory leak. > > > > > > The bug exists on PG10 ~ PG15(HEAD). > > > > > > For HEAD,PG14,PG13, to fix the memory leak, I think we should use > > > free_attrmap instead of pfree and release the no-longer-useful > > > attrmap When rebuilding the map info. > > > > > > For PG12,PG11,PG10, we only need to add the code to release the > > > no-longer-useful attrmap when rebuilding the map info. We can still > > > use > > > pfree() because the attrmap in back-branch is a single array like: > > > > > > entry->attrmap = palloc(desc->natts * sizeof(AttrNumber)); > > > > LGTM, thank you. > > > > LGTM as well. One thing I am not completely sure about is whether to make this > change in PG10 for which the final release is in Nov? > AFAICS, the leak can only occur after the relcache invalidation on the subscriber > which may or may not be a very frequent case. What do you guys think? > > Personally, I feel it is good to fix it in all branches including PG10. +1 Best regards, Hou zj
В списке pgsql-hackers по дате отправления: