From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Josh Kupershmidt <schmiddy(at)gmail(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: smallserial / serial2 |
Date: | 2011-06-22 15:25:54 |
Message-ID: | 880.1308756354@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Josh Kupershmidt <schmiddy(at)gmail(dot)com> writes:
> Hmph, looks like buildfarm members koi and jaguar are failing make check now:
> http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=koi&dt=2011-06-22%2008%3A06%3A00
> due to a difference in sequence.out. I didn't muck with the part about
> SELECT * FROM foo_seq_new;
> which is causing the diff, but it looks like the only difference is in
> the log_cnt column, which seems pretty fragile to rely on in a
> regression test. Maybe those SELECTS just shouldn't include log_cnt.
We've been around on this before:
http://archives.postgresql.org/pgsql-hackers/2008-08/msg01359.php
The eventual solution was bb3f839bfcb396c3066a31559d3a72ef0b4b5fae,
which is not consistent with what Robert just did, in fact he forgot
about that variant output file altogether (which probably means we'll
still get occasional failure reports).
That previous approach of adding extra expected files isn't going to
scale nicely if there are multiple places at risk ... but do we need
multiple places selecting the sequence contents? I remain of the
opinion that just omitting the value isn't good testing policy.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2011-06-22 15:26:21 | Re: ALTER TABLE lock strength reduction patch is unsafe |
Previous Message | Magnus Hagander | 2011-06-22 15:25:43 | Re: pg_dump vs malloc |