Table collision in join.sql and aggregates.sql
As we've been merging our code with 9.6, a couple developers have had
one-off failures in the join.sql and aggregates.sql test because the tables
T1, T2 and T3 have the wrong definitions.
Digging into it, I found that both files create the tables T1, T2, and T3
for a short period of time and then drop them. Since the parallel_schedule
file puts these two files into the same group, they can run concurrently.
If it happens that the the two files hit the T1, T2, T3 tests at the same
time, then you see the table definition problems.
I took the easy way of solving this and renamed the tables in
aggregates.sql to AGG1, AGG2, and AGG3. (Picked on aggregates.sql since it
had the T1, T2, T3 tests added in 9.6.)
Doug
- Salesforce
Attachments:
aggregates.patchtext/x-patch; charset=US-ASCII; name=aggregates.patchDownload+102-102
Douglas Doole <dougdoole@gmail.com> writes:
As we've been merging our code with 9.6, a couple developers have had
one-off failures in the join.sql and aggregates.sql test because the tables
T1, T2 and T3 have the wrong definitions.
Digging into it, I found that both files create the tables T1, T2, and T3
for a short period of time and then drop them. Since the parallel_schedule
file puts these two files into the same group, they can run concurrently.
If it happens that the the two files hit the T1, T2, T3 tests at the same
time, then you see the table definition problems.
Hmmm ... that would indeed be a problem, except that aggregate.sql's
tables are temp tables, which should mean that they are in a schema
different from the one that join.sql is putting its tables in. Are you
sure you've identified the issue correctly? Because if this doesn't
work, there are an awful lot of similar hazards elsewhere in the
regression tests.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
D'oh! The "temp" declaration had been removed from our test since we don't
use temp tables. I missed that when applying it to the community code.
You can ignore me now.
On Fri, Mar 31, 2017 at 4:01 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Show quoted text
Douglas Doole <dougdoole@gmail.com> writes:
As we've been merging our code with 9.6, a couple developers have had
one-off failures in the join.sql and aggregates.sql test because thetables
T1, T2 and T3 have the wrong definitions.
Digging into it, I found that both files create the tables T1, T2, and T3
for a short period of time and then drop them. Since theparallel_schedule
file puts these two files into the same group, they can run concurrently.
If it happens that the the two files hit the T1, T2, T3 tests at the same
time, then you see the table definition problems.Hmmm ... that would indeed be a problem, except that aggregate.sql's
tables are temp tables, which should mean that they are in a schema
different from the one that join.sql is putting its tables in. Are you
sure you've identified the issue correctly? Because if this doesn't
work, there are an awful lot of similar hazards elsewhere in the
regression tests.regards, tom lane