Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1w8bkd-000hed-0A for pgsql-hackers@arkaria.postgresql.org; Fri, 03 Apr 2026 10:27:43 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1w8bkb-00BHdj-27 for pgsql-hackers@arkaria.postgresql.org; Fri, 03 Apr 2026 10:27:42 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1w8bkb-00BHdV-0j for pgsql-hackers@lists.postgresql.org; Fri, 03 Apr 2026 10:27:41 +0000 Received: from smtp.outgoing.loopia.se ([93.188.3.37]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1w8bkZ-00000000MDd-0LJo for pgsql-hackers@lists.postgresql.org; Fri, 03 Apr 2026 10:27:41 +0000 Received: from s807.loopia.se (localhost [127.0.0.1]) by s807.loopia.se (Postfix) with ESMTP id 5D951588F19 for ; Fri, 03 Apr 2026 12:27:38 +0200 (CEST) Received: from s979.loopia.se (unknown [172.22.191.5]) by s807.loopia.se (Postfix) with ESMTP id 4A20358980F; Fri, 03 Apr 2026 12:27:38 +0200 (CEST) Received: from localhost (unknown [172.22.191.5]) by s979.loopia.se (Postfix) with ESMTP id 489EF10BC4C9; Fri, 03 Apr 2026 12:27:38 +0200 (CEST) X-Virus-Scanned: amavis at amavis.loopia.se X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.2 tagged_above=-999 required=6.2 tests=[ALL_TRUSTED=-1, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1] autolearn=disabled Authentication-Results: s474.loopia.se (amavis); dkim=pass (2048-bit key) header.d=yesql.se Received: from s899.loopia.se ([172.22.191.5]) by localhost (s474.loopia.se [172.22.190.14]) (amavis, port 10024) with LMTP id 3qbLXf24f4pY; Fri, 3 Apr 2026 12:27:37 +0200 (CEST) X-Loopia-Auth: user X-Loopia-User: daniel@yesql.se X-Loopia-Originating-IP: 89.255.232.236 Received: from smtpclient.apple (customer-89-255-232-236.stosn.net [89.255.232.236]) (Authenticated sender: daniel@yesql.se) by s899.loopia.se (Postfix) with ESMTPSA id 7FC932C8BAAC; Fri, 03 Apr 2026 12:27:37 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yesql.se; s=loopiadkim1707475645; t=1775212057; bh=QBOOKk7wOAX5rt/moAYOvtXNQMfbxDc5IBH4RlszHos=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=Gzbu1DRYW/FTwCa71U9ZHQv59I+NV53N6ATnINcadDWIT/JJKl2eg/F6Dd2e+amqa fNSIHcsoUGAu/mxYD4yrQm9JYXhLc1VFng0WSsLTFfd4ZOxmRQmM13mGHd97pSAzvx HfpzZUR7901skm5V4fp4YKt1Sa3+6457kOmgLdhNJny8jOyy9lSvqlp014Pdoiz0QP AkCbaECqk2mMR8zXP7kD6MUcGps5g3s8Q9xkO7uvVoB8ue/TeSTMQGmsHr93QgjL9N 5aAhFQBmV7tHi+ntD07m437vdgqJ6qBaZXuUAesproZ2XayL8pOyb8PclV7CHs9zAa Ipv/Vqmw56QLQ== Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51.11.2\)) Subject: Re: Flaky test in t/100_vacuumdb.pl: ordering assumption not stable under plan changes From: Daniel Gustafsson In-Reply-To: Date: Fri, 3 Apr 2026 12:27:27 +0200 Cc: PostgreSQL Hackers Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Andrei Lepikhov X-Mailer: Apple Mail (2.3776.700.51.11.2) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk > On 3 Apr 2026, at 08:42, Andrei Lepikhov wrote: >=20 > Hi, >=20 > I found that t/100_vacuumdb.pl has a fragile ordering check that fails = if the query plan for vacuumdb's catalogue query changes. I sometimes = see how this test fails when writing an optimisation-related extension. >=20 > The test checks that vacuumdb processes "Foo".bar before "Bar".baz: >=20 > qr/VACUUM\ \(SKIP_DATABASE_STATS\)\ "Foo".bar > .*VACUUM\ \(SKIP_DATABASE_STATS\)\ "Bar".baz > /sx, >=20 > Both tables being tested, "Foo".bar and "Bar".baz, are created empty. = This means pg_class.relpages is 0 for both and the sort order is = completely unstable. The output order depends entirely on which query = plan will be chosen. Any change in the planner that affects the plan for = this query, such as a new join path type or a cost model change, may = flip the order and cause the test to fail. >=20 > AFAICS, The fix is quite trivial. Change the test regex (in = 100_vacuumdb.pl) to use order-independent lookaheads instead of a = sequential match: >=20 > qr/(?=3D.*VACUUM\ \(SKIP_DATABASE_STATS\)\ "Foo"\.bar) > (?=3D.*VACUUM\ \(SKIP_DATABASE_STATS\)\ "Bar"\.baz) > /sx, >=20 > This makes the test robust regardless of the order in which the server = returns results. >=20 > Hence, it doesn=E2=80=99t change anything important. I think it = deserves to be back-patched down to v.16 (like the commit 2143d96dc7b = introduced this test) so other extensions can be stable with check-world = tests. Thanks for the report, I'll have a look. -- Daniel Gustafsson