Andrew Dunstan escribió:
> Alvaro Herrera wrote:
> >Bruce Momjian escribió:
> >
> >>Alvaro Herrera wrote:
> >>
> >>>Andrew Dunstan escribi?:
> >>>
> >>>
> >>>>Looks to me like the timestamptz test relies on the timestamp test (for
> >>>>timestamp_tbl) but they are set to run in parallel, so we have a race
> >>>>condition. Oops!
> >>>>
> >>>Good catch :-)
> >>>
> >>>I'd guess the answer is to move the tests using the timestamp_tbl to the
> >>>timestamp test.
> >>>
> >>OK, will do. Thanks for the diagnosis.
> >>
> >
> >Actually I have a patch ready for it.
> >
> >
>
> Well, the first question is "which table should these tests actually be
> using, and why?" Then they can be changed or moved as appropriate.
I just committed my patch before reading this comment. Maybe it was
rushed.
On the other hand, my thinking was that the submitter used the serial
schedule to test, so he wouldn't catch the problem because the timestamp
test comes before the timestamptz test and so there's no race condition
there. My conclusion would be that he intended to use the timestamp_tbl
table because that's what he did and it worked for him.
However, he did change one test from using the timestamptz_tbl into
using timestamp_tbl (and changed the to_char format in the process); I
fixed that by putting the new format in the timestamp test, and
restoring the original in timestamptz.
Lesson for today would be to make sure to run both the serial and the
parallel tests, several times, and that they both pass ...
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.