On 11/27/2014 12:51 PM, Tom Lane wrote: >> So test_decoding is fairly useful for users demonstrating that decoding >> > works, especially if they're also testing an external decoding module >> > and are unsure of where their replication problem is located, or what's >> > wrong with their HBA settings. For that reason it's important that >> > test_decoding be available via OS packages, which would give me some >> > reluctance to move it out of /contrib. > If we follow that reasoning we'll end up removing nothing from contrib. > There is no reason that end users should need to be performing such > testing; anyone who does have reason to do it will have a source tree > at hand.
1) Decoding extension "Slony-II", installed from PGXN, won't connect 2) Install test_decoding 3) Check if decoding is working and you can connect That's the scenario I'm looking at. It's useful for "is there something wrong with my decoding setup or is the decoding plugin broken?" And I can imagine quite a few users who don't have source installs needing to check that. That doesn't mean test_decoding needs to stay in contrib, just that it needs to be somewhere which goes into some common package. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
