On Thu, Apr 27, 2017 at 4:08 AM, Petr Jelinek <petr.jeli...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
