Обсуждение: Re: Table collision in join.sql and aggregates.sql

Поиск
Список
Период
Сортировка

Re: Table collision in join.sql and aggregates.sql

От
Tom Lane
Дата:
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



Re: Table collision in join.sql and aggregates.sql

От
Douglas Doole
Дата:
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:
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