Content-Type: multipart/mixed; boundary="------------0LhnESbE0nF35QAMBE8KyRjI"
Message-ID: <f5d1f4c2-6224-4797-be17-c86e77f96c9c@gmail.com>
Date: Wed, 19 Aug 2026 23:00:01 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
From: Alexander Lakhin <exclusion@gmail.com>
Subject: Test tidscan,sql is not immune to autovacuum in v14
To: pgsql-hackers <pgsql-hackers@postgresql.org>
Archived-At: 
 <https://www.postgresql.org/message-id/f5d1f4c2-6224-4797-be17-c86e77f96c9c%40gmail.com>
Precedence: bulk

This is a multi-part message in MIME format.
--------------0LhnESbE0nF35QAMBE8KyRjI
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hello hackers,

I spotted a very rare test failure (a single one in two years, at least)
generated by basilisk:
      tidscan                      ... FAILED       34 ms
...
diff -U3 /mnt/build/REL_14_STABLE/pgsql.build/../pgsql/src/test/regress/expected/tidscan.out 
/mnt/build/REL_14_STABLE/pgsql.build/src/test/regress/results/tidscan.out
--- /mnt/build/REL_14_STABLE/pgsql.build/../pgsql/src/test/regress/expected/tidscan.out
+++ /mnt/build/REL_14_STABLE/pgsql.build/src/test/regress/results/tidscan.out
@@ -242,10 +242,10 @@
  ----------------------------------------
   Aggregate
     ->  Hash Join
-         Hash Cond: (t1.ctid = t2.ctid)
-         ->  Seq Scan on tenk1 t1
+         Hash Cond: (t2.ctid = t1.ctid)
+         ->  Seq Scan on tenk1 t2
           ->  Hash
-               ->  Seq Scan on tenk1 t2
+               ->  Seq Scan on tenk1 t1
  (6 rows)

  SELECT count(*) FROM tenk1 t1 JOIN tenk1 t2 ON t1.ctid = t2.ctid;

and was intrigued enough to find a reliable reproducer for it.
With the following modification:
--- a/src/backend/optimizer/util/plancat.c
+++ b/src/backend/optimizer/util/plancat.c
@@ -188,6 +188,7 @@ get_relation_info(PlannerInfo *root, Oid relationObjectId, bool inhparent,
                 estimate_rel_size(relation, rel->attr_widths - rel->min_attr,
&rel->pages, &rel->tuples, &rel->allvisfrac);

+char *name = get_rel_name(relationObjectId); if (name != NULL && strcmp(name, "tenk1") == 0) pg_usleep(100000);
         /* Retrieve the parallel_workers reloption, or -1 if not set. */
         rel->rel_parallel_workers = RelationGetParallelWorkers(relation, -1);

and
test: tidscan analyze
in parallel_schedule (the full patch is attached), I get:
parallel group (2 tests):  analyze tidscan
      tidscan                      ... FAILED      900 ms
      analyze                      ... ok           63 ms

(The basilisk's log contain no autovacuum messages, but I guess it was
automatic analyze that processed tenk1 in the very lucky moment.)

Given the current statistics, we won't see failures of this ilk anymore,
because it is not reproduced in REL_15_STABLE..master, due to 74388a1ac +
4496020e6, which resulted in a different reltuples value returned for tenk1
during sanity_check/VACUUM and that indirectly affected the plan change.

[1] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=basilisk&dt=2026-06-15%2006%3A07%3A09

Best regards,
Alexander
--------------0LhnESbE0nF35QAMBE8KyRjI
Content-Type: text/x-patch; charset=UTF-8; name="repro-tidscan-failure.patch"
Content-Disposition: attachment; filename="repro-tidscan-failure.patch"
Content-Transfer-Encoding: base64

ZGlmZiAtLWdpdCBhL3NyYy9iYWNrZW5kL29wdGltaXplci91dGlsL3BsYW5jYXQuYyBiL3Ny
Yy9iYWNrZW5kL29wdGltaXplci91dGlsL3BsYW5jYXQuYwppbmRleCBlNzg1NmI1NGJiYi4u
NmRmMGVkNGRhMzYgMTAwNjQ0Ci0tLSBhL3NyYy9iYWNrZW5kL29wdGltaXplci91dGlsL3Bs
YW5jYXQuYworKysgYi9zcmMvYmFja2VuZC9vcHRpbWl6ZXIvdXRpbC9wbGFuY2F0LmMKQEAg
LTE2Nyw2ICsxNjcsNyBAQCBnZXRfcmVsYXRpb25faW5mbyhQbGFubmVySW5mbyAqcm9vdCwg
T2lkIHJlbGF0aW9uT2JqZWN0SWQsIGJvb2wgaW5ocGFyZW50LAogCQllc3RpbWF0ZV9yZWxf
c2l6ZShyZWxhdGlvbiwgcmVsLT5hdHRyX3dpZHRocyAtIHJlbC0+bWluX2F0dHIsCiAJCQkJ
CQkgICZyZWwtPnBhZ2VzLCAmcmVsLT50dXBsZXMsICZyZWwtPmFsbHZpc2ZyYWMpOwogCitj
aGFyICpuYW1lID0gZ2V0X3JlbF9uYW1lKHJlbGF0aW9uT2JqZWN0SWQpOyBpZiAobmFtZSAh
PSBOVUxMICYmIHN0cmNtcChuYW1lLCAidGVuazEiKSA9PSAwKSBwZ191c2xlZXAoMTAwMDAw
KTsKIAkvKiBSZXRyaWV2ZSB0aGUgcGFyYWxsZWxfd29ya2VycyByZWxvcHRpb24sIG9yIC0x
IGlmIG5vdCBzZXQuICovCiAJcmVsLT5yZWxfcGFyYWxsZWxfd29ya2VycyA9IFJlbGF0aW9u
R2V0UGFyYWxsZWxXb3JrZXJzKHJlbGF0aW9uLCAtMSk7CiAKZGlmZiAtLWdpdCBhL3NyYy90
ZXN0L3JlZ3Jlc3MvZXhwZWN0ZWQvYW5hbHl6ZS5vdXQgYi9zcmMvdGVzdC9yZWdyZXNzL2V4
cGVjdGVkL2FuYWx5emUub3V0Cm5ldyBmaWxlIG1vZGUgMTAwNjQ0CmluZGV4IDAwMDAwMDAw
MDAwLi5hMGI5Yzc0OGU4NgotLS0gL2Rldi9udWxsCisrKyBiL3NyYy90ZXN0L3JlZ3Jlc3Mv
ZXhwZWN0ZWQvYW5hbHl6ZS5vdXQKQEAgLTAsMCArMSBAQAorQU5BTFlaRSB0ZW5rMTsKZGlm
ZiAtLWdpdCBhL3NyYy90ZXN0L3JlZ3Jlc3MvcGFyYWxsZWxfc2NoZWR1bGUgYi9zcmMvdGVz
dC9yZWdyZXNzL3BhcmFsbGVsX3NjaGVkdWxlCmluZGV4IDUyZWY5MzgyOGZhLi42OGYyOTM1
MTBmMCAxMDA2NDQKLS0tIGEvc3JjL3Rlc3QvcmVncmVzcy9wYXJhbGxlbF9zY2hlZHVsZQor
KysgYi9zcmMvdGVzdC9yZWdyZXNzL3BhcmFsbGVsX3NjaGVkdWxlCkBAIC04Niw3ICs4Niw5
IEBAIHRlc3Q6IGJyaW5fYmxvb20gYnJpbl9tdWx0aQogIyAtLS0tLS0tLS0tCiAjIEFub3Ro
ZXIgZ3JvdXAgb2YgcGFyYWxsZWwgdGVzdHMKICMgLS0tLS0tLS0tLQotdGVzdDogY3JlYXRl
X3RhYmxlX2xpa2UgYWx0ZXJfZ2VuZXJpYyBhbHRlcl9vcGVyYXRvciBtaXNjIGFzeW5jIGRi
c2l6ZSBtaXNjX2Z1bmN0aW9ucyBzeXN2aWV3cyB0c3JmIHRpZCB0aWRzY2FuIHRpZHJhbmdl
c2NhbiBjb2xsYXRlLmljdS51dGY4IGluY3JlbWVudGFsX3NvcnQKK3Rlc3Q6IGNyZWF0ZV90
YWJsZV9saWtlIGFsdGVyX2dlbmVyaWMgYWx0ZXJfb3BlcmF0b3IgbWlzYyBhc3luYyBkYnNp
emUgbWlzY19mdW5jdGlvbnMgc3lzdmlld3MgdHNyZiB0aWQgdGlkcmFuZ2VzY2FuIGNvbGxh
dGUuaWN1LnV0ZjggaW5jcmVtZW50YWxfc29ydAorCit0ZXN0OiB0aWRzY2FuIGFuYWx5emUK
IAogIyBydWxlcyBjYW5ub3QgcnVuIGNvbmN1cnJlbnRseSB3aXRoIGFueSB0ZXN0IHRoYXQg
Y3JlYXRlcwogIyBhIHZpZXcgb3IgcnVsZSBpbiB0aGUgcHVibGljIHNjaGVtYQpkaWZmIC0t
Z2l0IGEvc3JjL3Rlc3QvcmVncmVzcy9zcWwvYW5hbHl6ZS5zcWwgYi9zcmMvdGVzdC9yZWdy
ZXNzL3NxbC9hbmFseXplLnNxbApuZXcgZmlsZSBtb2RlIDEwMDY0NAppbmRleCAwMDAwMDAw
MDAwMC4uYTBiOWM3NDhlODYKLS0tIC9kZXYvbnVsbAorKysgYi9zcmMvdGVzdC9yZWdyZXNz
L3NxbC9hbmFseXplLnNxbApAQCAtMCwwICsxIEBACitBTkFMWVpFIHRlbmsxOwo=

--------------0LhnESbE0nF35QAMBE8KyRjI--