Re: Logical Replication WIP

From: Andres Freund <andres(at)anarazel(dot)de>
To: Petr Jelinek <petr(at)2ndquadrant(dot)com>
Cc: Steve Singer <steve(at)ssinger(dot)info>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Craig Ringer <craig(at)2ndquadrant(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Logical Replication WIP
Date: 2016-11-12 19:18:25
Message-ID: 20161112191825.q3zmdr5cmchwxdz4@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2016-11-11 12:04:27 +0100, Petr Jelinek wrote:
> On 04/11/16 14:00, Andres Freund wrote:
> > Hi,
> >
> > + <sect1 id="catalog-pg-publication-rel">
> > + <title><structname>pg_publication_rel</structname></title>
> > +
> > + <indexterm zone="catalog-pg-publication-rel">
> > + <primary>pg_publication_rel</primary>
> > + </indexterm>
> > +
> > + <para>
> > + The <structname>pg_publication_rel</structname> catalog contains
> > + mapping between tables and publications in the database. This is many to
> > + many mapping.
> > + </para>
> >
> > I wonder if we shouldn't abstract this a bit away from relations to
> > allow other objects to be exported to. Could structure it a bit more
> > like pg_depend.
> >
>
> Honestly, let's not overdesign this. Change like that can be made in the
> future if we need it and I am quite unconvinced we do given that
> anything we might want to replicate will be relation. I understand that
> it might be useful to know what's on downstream in terms of objects at
> some point for some future functionality, but I am don't have idea how
> that functionality will look like so it's premature to guess what
> catalog structure it will need.

I slightly prefer to make it more generic right now, but I don't think
that's a blocker.

> > I still would very much like to move this outside of gram.y and just use
> > IDENTs here. Like how COPY options are handled.
> >
>
> Well, I looked into it and it means some loss of info in the error
> messages - mainly the error position in the query because utility
> statements don't get ParseState (unlike COPY). It might be worth the
> flexibility though.

Pretty sure that that's the case.

> > I also wonder if we want an easier to
> > extend form of pubinsert/update/delete (say to add pubddl, pubtruncate,
> > pub ... without changing the schema).
> >
>
> So like, text array that's then parsed everywhere (I am not doing
> bitmask/int definitely)?

Yes, that sounds good to me. Then convert it to individual booleans or a
bitmask when loading the publications into the in-memory form (which you
already do).

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2016-11-12 19:19:03 Re: Logical Replication WIP
Previous Message Andres Freund 2016-11-12 19:12:57 Re: PATCH: two slab-like memory allocators