On Wed, Apr 8, 2020 at 9:21 PM Peter Eisentraut <peter.eisentr...@2ndquadrant.com> wrote: > On 2020-04-08 13:16, Amit Langote wrote: > > On Wed, Apr 8, 2020 at 6:26 PM Peter Eisentraut > > <peter.eisentr...@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
logicalrep-partition-test-coverage-fixes.patch
Description: Binary data