Re: [GENERAL] pglogical vs. built-in logical replication in pg-10 - Mailing list pgsql-general

From Andres Freund
Subject Re: [GENERAL] pglogical vs. built-in logical replication in pg-10
Date
Msg-id 20170622173049.qflikmafiuqi5yd6@alap3.anarazel.de
Whole thread Raw
In response to Re: [GENERAL] pglogical vs. built-in logical replication in pg-10  (Achilleas Mantzios <achill@matrix.gatewaynet.com>)
Responses Re: [GENERAL] pglogical vs. built-in logical replication in pg-10  (Andreas Joseph Krogh <andreas@visena.com>)
Re: [GENERAL] pglogical vs. built-in logical replication in pg-10  (Achilleas Mantzios <achill@matrix.gatewaynet.com>)
List pgsql-general
On 2017-06-22 18:10:40 +0300, Achilleas Mantzios wrote:
> > Once again having pg_largeobject as a system-catalog prevents LOs
> > from working smoothly. Neither replication nor having LOs on a
> > different tablespace (by moving pg_largeobject) works.

> I think logical decoding was designed for supporting DML SQL commands
> (i.e. a finite set of commands) and not specific functions (lo_*)
> which by nature can be arbitrary, infinite and version specific.

That's not really the reason. The first reason its currently unsupported
is that LOs are stored in a system catalog, and currently all system
catalogs are excluded from the change stream.  The second problem is how
exactly to represent the changes - we can't represent it as the whole LO
being changed, as that'd increase the volume of WAL and replicated
writes dramatically.  Thus we need to invent an API that can represent
creation, deletion, and writes to arbitrary offsets, for output plugins.


> > I wish PG in some future version will address these quirks so one can operate on LOs more smoothly.

You're welcome to help...


Greetings,

Andres Freund


pgsql-general by date:

Previous
From: Andres Freund
Date:
Subject: Re: [GENERAL] pglogical vs. built-in logical replication in pg-10
Next
From: Andreas Joseph Krogh
Date:
Subject: Re: [GENERAL] pglogical vs. built-in logical replication in pg-10