| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Logical replication in the same cluster |
| Date: | 2017-05-01 18:22:47 |
| Message-ID: | CAH2-Wzmgh4J-RYPdnBJ=0QObQLT2n7L6tzARgw6QGqthtDi7ow@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Apr 28, 2017 at 9:28 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Thu, Apr 27, 2017 at 4:08 AM, Petr Jelinek
> <petr(dot)jelinek(at)2ndquadrant(dot)com> wrote:
>> Back when writing the original patch set, I was also playing with the
>> idea of having CREATE SUBSCRIPTION do multiple committed steps in
>> similar fashion to CREATE INDEX CONCURRENTLY but that leaves mess behind
>> on failure which also wasn't very popular outcome.
There is no inherent reason why the CREATE INDEX CONCURRENTLY style of
using multiple transactions makes it necessary to leave a mess behind
in the event of an error or hard crash. Is someone going to get around
to fixing the problem for CREATE INDEX CONCURRENTLY (e.g., having
extra steps to drop the useless index during recovery)? IIRC, this was
always the plan.
--
Peter Geoghegan
VMware vCenter Server
https://www.vmware.com/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2017-05-01 18:24:56 | Re: Logical replication in the same cluster |
| Previous Message | Tom Lane | 2017-05-01 18:19:15 | Re: BuildFarm client release 4.19 |