From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Achilleas Mantzios <achill(at)matrix(dot)gatewaynet(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: pglogical vs. built-in logical replication in pg-10 |
Date: | 2017-06-22 17:26:23 |
Message-ID: | 20170622172623.wb6kv6oe3nzebspy@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 2017-06-22 12:43:02 +0300, Achilleas Mantzios wrote:
> On 22/06/2017 11:21, Andreas Joseph Krogh wrote:
> > Hi.
> > 1. Why should one prefer built-in logical replication in pg-10 to pglogical, does it do anything pglogical doesn't?
> > It seems pglogical is more feature-rich...
> > 2. As I understand built-in logical replication in pg-10 doesn't support
> > large-objects, which we use a lot. Does pglogical replicate large
> > objects? I cannot find any notes about large-objects under "Limitations
> > and Restrictions":
> > https://www.2ndquadrant.com/en/resources/pglogical/pglogical-docs/
> You may do a simple test, create a table with a largeobject and try to read
> the logical stream, if it cannot represent the lo_import, lo_open, lowrite,
> lo_close (and I 'd bet they can't be encoded) then neither pglogical (being
> based on the same logical decoding technology) will support them.
There's nothing fundamental preventing us supporting large objects , but
indeed logical decoding at the moment doesn't support it. The technical
bits of extracting changes should actually be easy, it's a bit more
difficult to decide how to represent it to output plugins...
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2017-06-22 17:30:49 | Re: pglogical vs. built-in logical replication in pg-10 |
Previous Message | Adrian Klaver | 2017-06-22 17:13:41 | Re: Error when building new db using pg_restore |