Re: logical decoding and replication of sequences - Mailing list pgsql-hackers

From Tomas Vondra
Subject Re: logical decoding and replication of sequences
Date
Msg-id f0522a9b-eb33-20d4-06ca-b7668dcd434d@enterprisedb.com
Whole thread Raw
In response to Re: logical decoding and replication of sequences  ("Euler Taveira" <euler@eulerto.com>)
Responses Re: logical decoding and replication of sequences  ("Euler Taveira" <euler@eulerto.com>)
List pgsql-hackers

On 2/23/22 18:33, Euler Taveira wrote:
> On Wed, Feb 23, 2022, at 1:07 PM, Tomas Vondra wrote:
>> Maybe, but I don't think it's very common to have that many
>> schemas added to the same publication. And it probably does not
>> make much difference whether you have 1000 or 2000 items in the
>> list - either both are acceptable or unacceptable, I think.
>
> Wouldn't it confuse users? Hey, duplicate publication. How? Wait.
> Doh.
> 

I don't follow. Duplicate publications? This talks about rows in
pg_publication_namespace, not pg_publication.

>> I think just hard-coding this into CreatePublicationStmt would
>> work, but it'll be an issue once/if we start adding more options.
>> I'm not sure if it makes sense to replicate other relkinds, but
>> maybe DDL?
>
> Materialized view? As you mentioned DDL, maybe we can use the CREATE 
> PUBLICATION syntax to select which DDL commands we want to
> replicate.
> 

Well, yeah. But that doesn't really say whether to hard-code it into the
CREATE PUBLICATION syntax or cover it by PublicationObjSpec. Hard-coding
it also means we can't ALTER the publication to be FOR ALL TABLES etc.

regards

-- 
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: James Coleman
Date:
Subject: Re: Synchronizing slots from primary to standby
Next
From: Tomas Vondra
Date:
Subject: Re: Use generation context to speed up tuplesorts