Re: [HACKERS] Logical replication in the same cluster
От | Robert Haas |
---|---|
Тема | Re: [HACKERS] Logical replication in the same cluster |
Дата | |
Msg-id | CA+Tgmob_hy0uQS9vq_9rDBgjpww3D3jBZ6twAKZOwaZigo4C3g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Logical replication in the same cluster (Petr Jelinek <petr.jelinek@2ndquadrant.com>) |
Ответы |
Re: [HACKERS] Logical replication in the same cluster
|
Список | pgsql-hackers |
On Thu, Apr 27, 2017 at 4:08 AM, Petr Jelinek <petr.jelinek@2ndquadrant.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
В списке pgsql-hackers по дате отправления: