Re: Increasing test coverage of WAL redo functions

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Increasing test coverage of WAL redo functions
Date: 2014-11-19 21:58:21
Message-ID: 15824.1416434301@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> On 2014-11-19 19:59:33 +0200, Heikki Linnakangas wrote:
>> This grew "pg_dumpall | wc -c" from 5505689 to 6926066 bytes. The size of
>> the regression database grew, according to psql's "\l+" command grew from 45
>> MB to 57 MB. The amount of WAL generated by "make installcheck" grew from 75
>> MB to 104 MB.

> Why not just drop some of these slightly larger tables after the test?
> Then the maximum size of the database/the size of the dump doesn't
> increase as much? I don't think there's these are that interesting to
> look into after the test has finished.

While the post-run database size is interesting, I think the peak in-run
size is probably the more critical number, since that affects whether
buildfarm critters with limited disk space are going to run out.

Still, I agree that we could drop any such tables that don't add new
cases for pg_dump to think about.

Another thought, if we drop large tables at completion of their tests,
is that these particular tests ought not be run in parallel with each
other. That's just uselessly concentrating the peak space demand.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2014-11-19 22:09:45 amcheck prototype
Previous Message Josh Berkus 2014-11-19 21:16:35 Re: pg_multixact not getting truncated