Re: SSI 2PC coverage

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: Dan Ports <drkp(at)csail(dot)mit(dot)edu>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: SSI 2PC coverage
Date: 2011-08-18 13:57:34
Message-ID: 4E4D1A4E.4050905@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 07.07.2011 18:43, Kevin Grittner wrote:
> Heikki Linnakangas<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
>> On 05.07.2011 20:06, Kevin Grittner wrote:
>
>> There's two expected output files for this, one for
>> max_prepared_xacts=0 and another for the "normal" case. The
>> max_prepared_xacts=0 case isn't very interesting, since all the
>> PREPARE TRANSACTION commands fail. I think we should adjust the
>> test harness to not run these tests at all if
>> max_prepared_xacts=0. It would be better to skip the test and
>> print out a notice pointing out that it was not run, it'll just
>> give a false sense of security to run the test and report success,
>> when it didn't test anything useful.
>>
>> That alone cuts the size of the expected output to about 1 MB.
>
> OK. I'll work on this tonight unless Dan jumps in to claim it.

Committed. I removed the second expected output file, and marked the
prepared-transactions tests in the schedule as "ignore" instead. That
way if max_prepared_transactions=0, you get a notice that the test case
failed, but pg_regress still returns 0 as exit status.

>> That's much better, although it's still a lot of weight just for
>> expected output. However, it compresses extremely well, to about
>> 16 KB, so this isn't an issue for the size of distribution
>> tarballs and such, only for git checkouts and on-disk size of
>> extracted tarballs. I think that would be acceptable, although we
>> could easily cut it a bit further if we want to. For example
>> leaving out the word "step" from all the lines of executed test
>> steps would cut it by about 80 KB.
>
> That seems simple enough. Any other ideas?

I think it's good enough as it is. I did change the lexer slightly, to
trim whitespace from the beginning and end of SQL blocks. This cuts the
size of expected output a bit, and makes it look nicer anyway.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2011-08-18 13:57:36 Re: Displaying accumulated autovacuum cost
Previous Message Ashesh Vashi 2011-08-18 11:58:54 Re: PATCH: Compiling PostgreSQL using ActiveState Python 3.2