From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Christoph Berg <christoph(dot)berg(at)credativ(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <bruce(at)momjian(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Useless "Replica Identity: NOTHING" noise from psql \d |
Date: | 2014-03-28 00:17:36 |
Message-ID: | 5334BFA0.90102@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 03/27/2014 05:15 PM, Andres Freund wrote:
> On 2014-03-27 12:56:02 -0300, Alvaro Herrera wrote:
>> Also, there's the vcregress.pl business. The way it essentially
>> duplicates pg_upgrade/test.sh is rather messy; and now that
>> test_decoding also needs similar treatment, it's not looking so good.
>> Should we consider redoing that stuff in a way that allows both MSVC and
>> make-based systems to run those tests?
> I really hope test_decoding needs less scaffolding than this? There's
> much less going on in its test, right?
Yeah.
What I have done is create a quite small buildfarm module to run these
tests. See
<https://github.com/PGBuildFarm/client-code/commit/69c92f53bbe3748c13fa29aee0c39c8dd7210f1e>
It can be added to an existing buildfarm client installation and enabled
by adding TestDecoding to the list of modules in the buildfarm config
file. It will be included in the next release and enabled in that
release's sample config file.
See an example run at
<http://www.pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=crake&dt=2014-03-27%2023%3A40%3A15&stg=test-decoding-check>.
Larger questions can wait, but this makes a start on the immediate issue.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Kouhei Kaigai | 2014-03-28 00:45:30 | The way to get custom plan interface committed? (RE: Custom Scan APIs) |
Previous Message | Josh Berkus | 2014-03-27 22:44:45 | Re: History of WAL_LEVEL (archive vs hot_standby) |