From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Hannu Krosing <hannu(at)2ndQuadrant(dot)com> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: Cause of occasional buildfarm failures in sequence test |
Date: | 2008-08-31 17:50:27 |
Message-ID: | 11474.1220205027@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hannu Krosing <hannu(at)2ndQuadrant(dot)com> writes:
> On Sun, 2008-08-31 at 13:17 -0400, Tom Lane wrote:
>> So unless we want to just live with this test failing occasionally,
>> it seems we have two choices: redesign the behavior of nextval()
>> to be insensitive to checkpoint timing, or provide an alternate
>> regression "expected" file that matches the result with log_cnt = 31.
>> I favor the second answer --- I don't want to touch the nextval
>> logic, which has been stable for over six years.
> Maybe you get consistent result by just changing the test thus:
> checkpoint;
> create sequence foo;
> select nextval('foo');
> select nextval('foo');
> select * from foo;
Actually I think we'd need to put the checkpoint after the create,
but yeah we could do that. Or we could leave log_cnt out of the
set of columns displayed. I don't really favor either of those
answers though. They amount to avoiding testing of some code
paths ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2008-08-31 20:04:34 | Re: [HACKERS] Infrastructure changes for recovery |
Previous Message | Hannu Krosing | 2008-08-31 17:34:10 | Re: Cause of occasional buildfarm failures in sequence test |