Thread: 'with' regression tests fails rarely (and spuriously)

Hi,

I've twice seen the below failure when running tests in a loop (to
verify another rare issue in a patch is fixed):

diff -du10 /home/andres/src/postgresql/src/test/regress/expected/with.out
/home/andres/build/postgres/dev-assert/vpath/src/test/regress/results/with.out
--- /home/andres/src/postgresql/src/test/regress/expected/with.out      2020-07-21 15:03:11.239754712 -0700
+++ /home/andres/build/postgres/dev-assert/vpath/src/test/regress/results/with.out      2020-07-23 04:25:07.955839299
-0700
@@ -2207,28 +2207,30 @@
                Output: a_1.ctid, a_1.aa
          ->  CTE Scan on wcte
                Output: wcte.*, wcte.q2
    ->  Nested Loop
          Output: a_2.ctid, wcte.*
          Join Filter: (a_2.aa = wcte.q2)
          ->  Seq Scan on public.c a_2
                Output: a_2.ctid, a_2.aa
          ->  CTE Scan on wcte
                Output: wcte.*, wcte.q2
-   ->  Nested Loop
+   ->  Hash Join
          Output: a_3.ctid, wcte.*
-         Join Filter: (a_3.aa = wcte.q2)
+         Hash Cond: (a_3.aa = wcte.q2)
          ->  Seq Scan on public.d a_3
                Output: a_3.ctid, a_3.aa
-         ->  CTE Scan on wcte
+         ->  Hash
                Output: wcte.*, wcte.q2
-(38 rows)
+               ->  CTE Scan on wcte
+                     Output: wcte.*, wcte.q2
+(40 rows)
 
 -- error cases
 -- data-modifying WITH tries to use its own output
 WITH RECURSIVE t AS (
        INSERT INTO y
                SELECT * FROM t
 )
 VALUES(FALSE);
 ERROR:  recursive query "t" must not contain data-modifying statements
 LINE 1: WITH RECURSIVE t AS (


Searching the archives didn't unearth other reports of the same.


This was the first failure after 404 iterations of installcheck, so it's
clearly not a common occurance on my machine.

Greetings,

Andres Freund

Andres Freund <andres@anarazel.de> writes:
> I've twice seen the below failure when running tests in a loop (to
> verify another rare issue in a patch is fixed):

Weird.  It sort of looks like autovacuum came along and changed the
stats for those tables, but I didn't think they were big enough to
draw autovac's attention.

            regards, tom lane

Hi,

On 2020-07-23 13:05:32 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > I've twice seen the below failure when running tests in a loop (to
> > verify another rare issue in a patch is fixed):
> 
> Weird.  It sort of looks like autovacuum came along and changed the
> stats for those tables, but I didn't think they were big enough to
> draw autovac's attention.

Hm. I guess I could run them again after enabling more logging. Don't
really have a better idea. Probably not worth investing more energy into
if I can't readily reproduce over night.

Greetings,

Andres Freund