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

From Achilleas Mantzios
Subject Re: [GENERAL] pglogical vs. built-in logical replication in pg-10
Date
Msg-id 0f6a2aff-1312-a605-80b3-b66fa7a05243@matrix.gatewaynet.com
Whole thread Raw
In response to Re: [GENERAL] pglogical vs. built-in logical replication in pg-10  (Andres Freund <andres@anarazel.de>)
List pgsql-general
On 22/06/2017 20:30, Andres Freund wrote:
> 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.

Thanx for the insight.

>
>>> 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
>
>

--
Achilleas Mantzios
IT DEV Lead
IT DEPT
Dynacom Tankers Mgmt



pgsql-general by date:

Previous
From: Арсен Арутюнян
Date:
Subject: [GENERAL] Re[2]: [GENERAL] SPI_execute_plan and vardata
Next
From: Арсен Арутюнян
Date:
Subject: [GENERAL] BUG in Prepared transactions from C code using JSON