Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On Thu, Feb 4, 2016 at 11:58 PM, Stas Kelvich <s(dot)kelvich(at)postgrespro(dot)ru> wrote:
>> On 04 Feb 2016, at 12:59, Michael Paquier <michael(dot)paquier(at)gmail(dot)com> wrote:
>>> 0) There are several routines that does actual checking, like is/command_ok/command_fails. I think it will be very handy to have wrappers psql_ok/psql_fails that calls psql through the command_ok/fails.
>>
>> Do you have a test case in mind for it?
>
> Yes, I’ve used that to test prepare/commit while recovery (script attached, it’s in WIP state, i’ll submit that later along with other twophase stuff).

Oh, OK, now I see. Well it seems to make sense for your case, though
it does not seem to be directly linked to the patch here. We could
incrementally add something on top of the existing infrastructure that
gets into the code tree once the 2PC patch gets in a more advanced
shape.

>>> 2) --enable-tap-tests deserves mention in test/recovery/README and more obvious error message when one trying to run make check in test/recovery without --enable-tap-tests.
>>
>> When running without --enable-tap-tests from src/test/recovery you
>> would get the following error per how prove_check is defined:
>> "TAP tests not enabled"
>
> Yes, but that message doesn’t mention --enable-tap-tests and README also silent about that too. I didn’t know about that flag and had to search in makefiles for this error message to see what conditions leads to it. I think we can save planet from one more stackoverflow question if the error message will mention that flag.

Well, that works for the whole TAP test infrastructure and not really
this patch only. Let's not forget that the goal of this thread is to
provide a basic set of tests and routines to help people building test
cases for more advanced clustering scenarios, so I'd rather not
complicate the code with side things and remain focused on the core
problem.
--
Michael