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

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
Cc: michael(dot)paquier(at)gmail(dot)com, noah(at)leadboat(dot)com, amir(dot)rohan(at)zoho(dot)com, robertmhaas(at)gmail(dot)com, andres(at)2ndquadrant(dot)com, pgsql-hackers(at)postgresql(dot)org, gsmith(at)gregsmith(dot)com
Subject: Re: Re: In-core regression tests for replication, cascading, archiving, PITR, etc.
Date: 2016-02-26 18:43:14
Message-ID: 20160226184314.GA205945@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Kyotaro HORIGUCHI wrote:

> So, I'd like to propose four (or five) changes to this harness.
> - prove_check to remove all in tmp_check
> - TestLib to preserve temporary directories/files if the current
> test fails.
> - PostgresNode::get_new_node to create data directory with
> meaningful basenames.
> - PostgresNode::psql to return a list of ($stdout, $stderr) if
> requested. (The previous behavior is not changed)
> - (recovery/t/00x_* gives test number to node name)
> As a POC, the attached diff will appliy on the 0001 and (fixed)
> 0003 patches.

These changes all seem very reasonable to me. I'm not so sure about the
last one. Perhaps the framework ought to generate an appropriate subdir
name using the test file name plus the node name, so that instead of
tmp_XXXX it becomes tmp_001_master_XXXX or something like that? Having
be a coding convention doesn't look real nice to me.

I didn't try to apply your patch but I'm fairly certain it would
conflict with what's here now; can you please rebase and resend?

Álvaro Herrera
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Euler Taveira 2016-02-26 18:58:31 Re: [PATCH] fix DROP OPERATOR to reset links to itself on commutator and negator
Previous Message Alvaro Herrera 2016-02-26 18:30:29 Re: The plan for FDW-based sharding