Re: adding partitioned tables to publications

From: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
To: Amit Langote <amitlangote09(at)gmail(dot)com>
Cc: Rafia Sabih <rafia(dot)pghackers(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: adding partitioned tables to publications
Date: 2020-01-28 09:11:35
Message-ID: f3e27805-3e23-970c-62b0-bb7b5c2f0415@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2020-01-23 11:10, Amit Langote wrote:
> On Wed, Jan 22, 2020 at 2:38 PM Amit Langote<amitlangote09(at)gmail(dot)com> wrote:
>> Other than that, the updated patch contains following significant changes:
>>
>> * Changed pg_publication.c: GetPublicationRelations() so that any
>> published partitioned tables are expanded as needed
>>
>> * Since the pg_publication_tables view is backed by
>> GetPublicationRelations(), that means subscriptioncmds.c:
>> fetch_table_list() no longer needs to craft a query to include
>> partitions when needed, because partitions are included at source.
>> That seems better, because it allows to limit the complexity
>> surrounding publication of partitioned tables to the publication side.
>>
>> * Fixed the publication table DDL to spot more cases of tables being
>> added to a publication in a duplicative manner. For example,
>> partition being added to a publication which already contains its
>> ancestor and a partitioned tables being added to a publication
>> (implying all of its partitions are added) which already contains a
>> partition
> On second thought, this seems like an overkill. It might be OK after
> all for both a partitioned table and its partitions to be explicitly
> added to a publication without complaining of duplication. IOW, it's
> the user's call whether it makes sense to do that or not.

This structure looks good now.

However, it does seem unfortunate that in pg_get_publication_tables() we
need to postprocess the result of GetPublicationRelations(). Since
we're already changing the API of GetPublicationRelations(), couldn't we
also make it optionally not include partitioned tables?

For the test, perhaps add test cases where partitions are attached and
detached so that we can see whether their publication relcache
information is properly updated. (I'm not doubting that it works, but
it would be good to have a test for, in case of future restructuring.)

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro Horiguchi 2020-01-28 09:12:07 Re: standby apply lag on inactive servers
Previous Message Amit Kapila 2020-01-28 09:06:16 Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions