| 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: | 5477.1359646778@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeff Janes | 2013-01-31 16:32:48 | Re: Should pg_dump dump larger tables first? |
| Previous Message | Andrew Dunstan | 2013-01-31 15:38:04 | Re: Strange Windows problem, lock_timeout test request |