From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com> |
Cc: | 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-04-28 16:28:26 |
Message-ID: | CA+Tgmob_hy0uQS9vq_9rDBgjpww3D3jBZ6twAKZOwaZigo4C3g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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. I wonder how bad it
> would be if we created all the stuff for subscription but in disabled
> form, then committed, then created slot outside of tx (slot creation is
> not transactional anyway) and then switched the subscription to enabled
> (if needed) in next tx. It would still leave subscription behind on
> failure but a) user would see the failure, b) the subscription would be
> inactive so no active harm from it. We also already prevent running
> CREATE SUBSCRIPTION inside transaction block when automatic slot
> creation is chosen so there is no difference from that perspective.
Sounds like a solid approach. There's no way to end up with a remote
object without also ending up with a logical object, which seems like
it greatly reduces the chances of confusion and error.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2017-04-28 16:29:18 | Re: convert EXSITS to inner join gotcha and bug |
Previous Message | Robert Haas | 2017-04-28 16:25:04 | Re: Declarative partitioning - another take |