Re: [HACKERS] Detecting schema changes during logical replication - Mailing list pgsql-hackers

From Daniele Varrazzo
Subject Re: [HACKERS] Detecting schema changes during logical replication
Date
Msg-id CA+mi_8ZsdQYPnQdre8ishq7UUjG9BpbOWCqUJ=gaWAMjrxov+Q@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Detecting schema changes during logical replication  (Craig Ringer <craig.ringer@2ndquadrant.com>)
List pgsql-hackers
On Mon, May 8, 2017 at 3:48 AM, Craig Ringer
<craig.ringer@2ndquadrant.com> wrote:

> Sounds like you're reimplementing pglogical
> (http://2ndquadrant.com/pglogical) on top of a json protocol.

The fact the protocol is JSON is more a detail, but it's a good start
as it's human-readable.

> [...]
> I have no reason to object to your doing it yourself, and you're welcome to
> use pglogical as a reference for how to do things (see the license). It just
> seems like a waste.

Logical Replication, for the first time, offers a way to implement a
replication solution that is not several layers away from the
database. Or even: for the first time is something I understand.

Using the logical replication we can perform some manipulation of the
data I will want to use (tables not necessarily in the same places,
schemas not necessarily matching). In particular one not-really-minor
annoyance of the current system is that adding a column of the master
regularly breaks the replica, and pglogical doesn't resolve this
problem. We currently use certain features of Londiste (tables living
in different schemas, slightly different data types with the same
textual representation, extra columns on the slave...) that are
against pglogical requirements, but which can be implemented no
problem is a customised replication solution built on top of streaming
replication.

All in all I'm more thrilled by the idea of having a database throwing
a stream of changes at me in a format I can reinterpret, allowing me
to write in a target database with a high degree of configurability in
the middle (i.e. I just have a Python script receiving the data,
munging them and then performing queries), then a complete but
schema-rigid replication solution.


-- Daniele



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] Fix a typo in snapmgr.c
Next
From: Ashutosh Sharma
Date:
Subject: Re: [HACKERS] Page Scan Mode in Hash Index