Re: Failure with regression test largeobject if pg_regress invoked from external paths

On Wed, Jan 6, 2016 at 12:29 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Michael Paquier <michael(dot)paquier(at)gmail(dot)com> writes:
>> On Wed, Jan 6, 2016 at 11:35 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> Um ... what exactly is the triggering condition here?
>
>> Perhaps my previous email was not clear enough. Attached is a small
>> script that emulates what my colleague infrastructure is doing on a
>> running instance.
>
> I see; so the point is you haven't cd'ed into src/test/regress.

Yep.

> I'm not sure if that's a case we ought to support or not. In particular,
> it's pretty unclear what is the benefit of this script compared to
> "make -C $PG_SRC/src/test/regress check". The script certainly will break
> anytime we change the set of arguments the Makefile passes to pg_regress,
> which we have done before and no doubt will do again.

Cross-platform testing is eased a bit in the testing infrastructure I
poke at from time to time: on Windows particularly the stuff I work on
is compiled using MSVC, and bundled within an MSI, several MSI
actually each one with a couple of different characteristics, and the
files of input/output/sql/expected are saved separately, then
redeployed for the tests. Then when testing you can use the same
single code path that kicks pg_regress. There is the burden to change
this code each time the arguments of pg_regress are changed, but this
outweighs the fact that there is no need to go through vcregress.pl
that relies on having the source code around, particularly that we do
as well automated testing of MSI upgrade or things related to Postgres
being integrated in a set of products that have different requirements
and different stability tests. So having the MSI with compiled things
and not the source code itself is a gain in my case, at least I think
so :)

> Again, I don't see much harm in the patch you propose, it's more a
> question of should we contract to support this use-case. It's not
> zero cost to do so; we might for example be able to get rid of some
> (in/out)put/*.source files if we didn't need to substitute @abs_builddir@
> in them. Those things are a PITA to maintain, too, so I'm not very
> eager to add on more reasons why tests would need them.

I have no clear answer to that either, it depends on where we want
things to go. Anyway, having both relative and absolute paths in this
test case is clearly a no-win. I agree that we could definitely remove
at least most the @abs_builddir@ markups which is used everywhere
except create_function if we take the direction of minimizing the
input/output files, but still it seems to me that even if this
facilitates a bit the life of maintainers, this has as cost a
reduction of the test portability, and it is not like those files are
actually modified every day.
--
Michael