Re: pglogical - logical replication contrib module

From: Steve Singer <steve(at)ssinger(dot)info>
To: Craig Ringer <craig(at)2ndquadrant(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pglogical - logical replication contrib module
Date: 2016-02-03 02:31:54
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 01/26/2016 10:43 AM, Craig Ringer wrote:
> On 23 January 2016 at 11:17, Steve Singer <steve(at)ssinger(dot)info
> <mailto:steve(at)ssinger(dot)info>> wrote:

> ** Schema changes involving rewriting big tables
> Sometimes you have a DDL change on a large table that will involve
> a table rewrite and the best way of deploying the change is to
> make the DDL change
> on a replicate then once it is finished promote the replica to the
> origin in some controlled fashion. This avoids having to lock the
> table on the origin for hours.
> pglogical seems to allow minor schema changes on the replica such
> as changing a type but it doesn't seem to allow a DO INSTEAD
> trigger on the replica. I don't think pglogical currently meets
> this use case particularly well
> I'm not sure I fully understand that one.

Say you have a table A with column b

and the next version of your application you want to create a second
table B that has column B

create table B (b text);
insert into B select b from a;
alter table a drop column b;

but you want to do this on a replica because it is a very big table and
you want to minimize downtown.

You could have a trigger on the replica that performed updates on B.b
instead of A except triggers don't seem to get run on the replica.

> Craig Ringer
> PostgreSQL Development, 24x7 Support, Training & Services


In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim Nasby 2016-02-03 02:33:44 Re: Add links to commit fests to patch summary page
Previous Message Peter Eisentraut 2016-02-03 02:31:32 Re: [PATCH] better systemd integration