Skip site navigation (1) Skip section navigation (2)

Re: Strange Windows problem, lock_timeout test request

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Zoltán Böszörményi <zb(at)cybertec(dot)at>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Hari Babu <haribabu(dot)kommi(at)huawei(dot)com>, "'Craig Ringer'" <craig(at)2ndquadrant(dot)com>, 'Hans-Jürgen Schönig' <hs(at)cybertec(dot)at>, "'Ants Aasma'" <ants(at)cybertec(dot)at>, "'PostgreSQL Hackers'" <pgsql-hackers(at)postgresql(dot)org>, "'Amit kapila'" <amit(dot)kapila(at)huawei(dot)com>
Subject: Re: Strange Windows problem, lock_timeout test request
Date: 2013-01-31 15:39:38
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
=?ISO-8859-1?Q?Zolt=E1n_B=F6sz=F6rm=E9nyi?= <zb(at)cybertec(dot)at> writes:
> 2013-01-31 15:22 keltezssel, Alvaro Herrera rta:
>> That sounds a lot more difficult than just using "make installcheck" and
>> configure the running server with zero prepared xacts ...

> It didn't occur to me to use "make installcheck" for this one.

> What is strange though is why prepared_xacts_1.out exists
> at all, since pg_regress.c / make check seems to set
> max_prepared_transactions on Windows, too.

Alvaro told you why: so that the tests wouldn't report failure in
"make installcheck" against a stock-configuration server.

BTW, 99% of the time you can update alternative expected files by
applying the same patch to them as you did to the tested version.
At least that usually works for me, and it can be a lot easier than
arranging to duplicate the environment the alternative file is
meant for.

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Jeff JanesDate: 2013-01-31 16:32:48
Subject: Re: Should pg_dump dump larger tables first?
Previous:From: Andrew DunstanDate: 2013-01-31 15:38:04
Subject: Re: Strange Windows problem, lock_timeout test request

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group