Re: no test programs in contrib

From: Josh Berkus <josh(at)agliodbs(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: no test programs in contrib
Date: 2014-11-28 20:44:17
Message-ID: 5478DEA1.8060404@agliodbs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2014-11-28 20:54:53 Re: no test programs in contrib
Previous Message Tom Lane 2014-11-28 19:18:10 Re: Marginal performance improvement: replace bms_first_member loops