Hello,
Continuing my testing with pglogical:
It is very easy to end up in a broken state with pglogical. This isn't
all that big of a deal because it is relatively easy to end up in a
broken state with streaming replication as well. However, with streaming
the replication the various components are of a known quantity. Using
the wrong replication slot? Change the replication slot name to the
correct one. Can't connect to the master? Check the log for pg_hba.conf
errors, things like that.
With pg_logical it is a little more obtuse. You can end up with a
replication slot (not to mention other things) that you are not able to
get rid of because it is in use but it is difficult to figure out what
is using it. I was able to plow through this by investigating the
relations that reside under the schema pglogical. I do not think that is
what our users need though.
In order for pg_logical to be further considered into core I think we
need a lot more documentation. Every single relation needs to be
documented. I was able to reasonably tell myself, "Oh,
pglogical.subscriptions probably relates to
pglogical.drop/create_subscription()" but that isn't going to be the norm.
Further, we may also want to consider having proper views in order to
get information about what is going on:
pglogical.list_subscribers
pglogical.list_nodes
etc....
Sincerely,
Joshua D. Drake
P.S. there is also a bug where pglogical does not release lwlocks which
is resulting in a dot release shortly (per Github)
--
Command Prompt, Inc. http://the.postgres.company/ +1-503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Everyone appreciates your honesty, until you are honest with them.