RE: Table refer leak in logical replication - Mailing list pgsql-hackers

From houzj.fnst@fujitsu.com
Subject RE: Table refer leak in logical replication
Date
Msg-id OS0PR01MB57160AE18728204E6B2E1FAC94769@OS0PR01MB5716.jpnprd01.prod.outlook.com
Whole thread Raw
In response to Re: Table refer leak in logical replication  (Masahiko Sawada <sawada.mshk@gmail.com>)
Responses Re: Table refer leak in logical replication
List pgsql-hackers
> > > insert into test values (6);
> > >
> > > It seems an issue about reference leak. Anyone can fix this?
> >
> > It seems ExecGetTriggerResultRel will reopen the target table because it
> cannot find an existing one.
> > Storing the opened table in estate->es_opened_result_relations seems
> solves the problem.
> 
> It seems like commit 1375422c is related to this bug. The commit introduced a
> new function ExecInitResultRelation() that sets both
> estate->es_result_relations and estate->es_opened_result_relations. I
> think it's better to use ExecInitResultRelation() rather than directly setting
> estate->es_opened_result_relations. It might be better to do that in
> create_estate_for_relation() though. Please find an attached patch.
> 
> Since this issue happens on only HEAD and it seems an oversight of commit
> 1375422c, I don't think regression tests for this are essential.

It seems we can not only use ExecInitResultRelation.
In function ExecInitResultRelation, it will use ExecGetRangeTableRelation which
will also open the target table and store the rel in "Estate->es_relations".
We should call ExecCloseRangeTableRelations at the end of apply_handle_xxx to
close the rel in "Estate->es_relations".

Attaching the patch with this change.

Best regards,
houzj


Attachment

pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: Binary search in ScalarArrayOpExpr for OR'd constant arrays
Next
From: Jaime Casanova
Date:
Subject: document that brin's autosummarize parameter is off by default