Robert Treat

+1 for a PR to this repo :-)

This is also touched on in the FAQ: https://github.com/citusdata/pg_auto_failover/blob/master/docs/faq.rst#the-monitor-is-a-spof-in-pg_auto_failover-design-how-should-we-handle-that

Perhaps you would consider re-licensing this project under the Postgres license, which would allow others to more easily continue the (very nice) work you have started?

ISTM this is one of those cases where if we were starting from day 1, we might be inclined to go success|failure, but the cost to make the change (aka...

In case anyone was thinking of implementing things this way, I'll +1 the idea to use pg_get_functiondef. Note it can be difficult to work with, but something like the following...

@esatterwhite @pmwebster Best as I can remember, we always tested this by hand... install the extension into a fresh database, upgrade extension, then test basic sending of messages. I think...

Speaking only for myself, I'm a bit bogged down with actual work and other more pressing community work in light of the pending PostgreSQL 12 release. If a couple of...

Please see PR https://github.com/omniti-labs/pg_amqp/pull/27 as the likely fix for this issue.

After some discussion between @vventirozos and myself, ISTM the correct answer is to set the config tables as "dumpable" in the extension. See https://www.postgresql.org/docs/current/extend-extensions.html#EXTEND-EXTENSIONS-CONFIG-TABLES more more information on this. I...