Horton

Thread

Commits

  1. Fix overly generic name in with.sql test.

  2. Clean up duplicate table and function names in regression tests.

  1. Tests "with" and "alter_table" suffer from name clash

    Thomas Munro <thomas.munro@gmail.com> — 2021-12-30T02:12:04Z

    Hi,

With unlucky scheduling you can get a failure like this:

https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hoverfly&dt=2021-12-22%2010%3A51%3A32

Suggested fix attached.

  2. Re: Tests "with" and "alter_table" suffer from name clash

    Tom Lane <tgl@sss.pgh.pa.us> — 2021-12-30T02:27:09Z

    Thomas Munro <thomas.munro@gmail.com> writes:
> With unlucky scheduling you can get a failure like this:
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hoverfly&dt=2021-12-22%2010%3A51%3A32
> Suggested fix attached.

Looks reasonable.  We really should avoid using such common
names for short-lived tables in any case --- it's an invitation
to trouble.  So I'd vote for changing the other use of "test", too.

			regards, tom lane

  3. Re: Tests "with" and "alter_table" suffer from name clash

    Thomas Munro <thomas.munro@gmail.com> — 2021-12-30T04:25:40Z

    On Thu, Dec 30, 2021 at 3:27 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Looks reasonable.  We really should avoid using such common
> names for short-lived tables in any case --- it's an invitation
> to trouble.  So I'd vote for changing the other use of "test", too.

In fact only REL_10_STABLE had the problem, because commit 2cf8c7aa
already fixed the other instance in later branches.  I'd entirely
forgotten that earlier discussion, which apparently didn't quite go
far enough.   So I only needed to push the with.sql change.  Done.

  4. Re: Tests "with" and "alter_table" suffer from name clash

    Tom Lane <tgl@sss.pgh.pa.us> — 2021-12-30T04:50:32Z

    Thomas Munro <thomas.munro@gmail.com> writes:
> In fact only REL_10_STABLE had the problem, because commit 2cf8c7aa
> already fixed the other instance in later branches.  I'd entirely
> forgotten that earlier discussion, which apparently didn't quite go
> far enough.   So I only needed to push the with.sql change.  Done.

Hah, I thought this felt familiar.  So the real problem is that
my backpatch (b15a8c963) only fixed half of the hazard.  Sigh.

			regards, tom lane