Re: adding partitioned tables to publications - Mailing list pgsql-hackers

From Amit Langote
Subject Re: adding partitioned tables to publications
Date
Msg-id CA+HiwqGkknVb+ccLVkgw1DoBYPzpuR43L+aT1eOT8dVEtiedtw@mail.gmail.com
Whole thread Raw
In response to Re: adding partitioned tables to publications  (Amit Langote <amitlangote09@gmail.com>)
Responses Re: adding partitioned tables to publications  (Petr Jelinek <petr@2ndquadrant.com>)
Re: adding partitioned tables to publications  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-hackers
On Fri, Apr 3, 2020 at 6:34 PM Amit Langote <amitlangote09@gmail.com> wrote:
> I am checking test coverage at the moment and should have the patches
> ready by sometime later today.

Attached updated patches.

I confirmed using a coverage build that all the new code in
logical/worker.c due to 0002 is now covered. For some reason, coverage
report for pgoutput.c doesn't say the same thing for 0003's changes,
although I doubt that result.  It seems strange to believe that *none*
of the new code is tested.  I even checked by adding debugging elog()s
next to the lines that the coverage report says aren't exercised,
which tell me that that's not true. Perhaps my coverage build is
somehow getting messed up, so it would be nice if someone with
reliable coverage builds can confirm one way or the other. I will
continue to check what's wrong.

I fixed a couple of bugs in 0002. One of the bugs was that the
"partition map" hash table in logical/relation.c didn't really work,
so logicalrep_partition_would() always create a new entry.

In 0003, changed the publication parameter name to publish_via_partition_root.

-- 
Thank you,

Amit Langote
EnterpriseDB: http://www.enterprisedb.com

Attachment

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: where should I stick that backup?
Next
From: Alexey Kondratov
Date:
Subject: Re: [HACKERS] make async slave to wait for lsn to be replayed