On Wed, Apr 8, 2020 at 9:21 PM Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:
> On 2020-04-08 13:16, Amit Langote wrote:
> > On Wed, Apr 8, 2020 at 6:26 PM Peter Eisentraut
> > <peter.eisentraut@2ndquadrant.com> wrote:
> >> All committed.
> >>
> >> Thank you and everyone very much for working on this. I'm very happy
> >> that these two features from PG10 have finally met. :)
> >
> > Thanks a lot for reviewing and committing.
> >
> > prion seems to have failed:
> > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=prion&dt=2020-04-08%2009%3A53%3A13
>
> This comes from -DRELCACHE_FORCE_RELEASE.
I'm seeing some funny stuff on such a build locally too, although
haven't been able to make sense of it yet.
> > Also, still unsure why the coverage report for pgoutput.c changes not good:
> > https://coverage.postgresql.org/src/backend/replication/pgoutput/pgoutput.c.gcov.html
>
> I think this is because the END { } section in PostgresNode.pm shuts
> down all running instances in immediate mode, which doesn't save
> coverage properly.
Thanks for that tip. Appending the following at the end of the test
file has fixed the coverage reporting for me.
I noticed the following coverage issues:
1. The previous commit f1ac27bfd missed a command that I had included
to cover the following blocks of apply_handle_tuple_routing():
1165 : else
1166 : {
1167 0 : remoteslot =
ExecCopySlot(remoteslot, remoteslot_part);
1168 0 : slot_getallattrs(remoteslot);
1169 : }
...
1200 2 : if (map != NULL)
1201 : {
1202 0 : remoteslot_part =
execute_attr_map_slot(map->attrMap,
1203 :
remoteslot,
1204 :
remoteslot_part);
1205 : }
2. Now that I am able to see proper coverage fo
publish_via_partition_root related changes, I can see that a block in
pgoutput_change() is missing coverage
The attached fixes these coverage issues.
--
Amit Langote
EnterpriseDB: http://www.enterprisedb.com
