Re: [GENERAL] pglogical vs. built-in logical replication in pg-10
От | Achilleas Mantzios |
---|---|
Тема | Re: [GENERAL] pglogical vs. built-in logical replication in pg-10 |
Дата | |
Msg-id | 0f6a2aff-1312-a605-80b3-b66fa7a05243@matrix.gatewaynet.com обсуждение исходный текст |
Ответ на | Re: [GENERAL] pglogical vs. built-in logical replication in pg-10 (Andres Freund <andres@anarazel.de>) |
Список | 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 по дате отправления: