| From: | Manu <manuelreyesbravo(at)gmail(dot)com> |
|---|---|
| To: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Cc: | shihao zhong <zhong950419(at)gmail(dot)com>, David Rowley <dgrowleyml(at)gmail(dot)com>, Guofeng Lin <guofenglinux(at)gmail(dot)com> |
| Subject: | Re: [PG19] Wrong results from Memoize with a nondeterministic collation |
| Date: | 2026-10-09 17:37:50 |
| Message-ID: | 179156747020.330936.13366793239698644432@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi Shihao,
> Yes, please post the hand-placed hunks for 14 to 16.
Attached, one per branch. In 14-16 paraminfo_get_equal_hashops has no
list_member() dedup, so the block goes right after the clause's outer
expr is chosen and before it is appended to *param_exprs, so the
canonicalized expr is what becomes the cache key.
I re-verified each on the current tip of its branch (14.24, 15.19,
16.15): make check passes, and the stress oracle (enable_memoize on vs
off over a matrix of nondeterministic-collation shapes) goes from 39/52
wrong cases to 0/52, with identical row counts. For contrast I also
built the mechanical fuzz-placed hunk: it compiles and make check still
passes, but it puts the block after the append and leaves all 39 cases
wrong, which is why these are placed by hand.
The LEFT JOIN case is the one reachable on 14-16; the anti-join path is
19+ only.
Regards,
Manu
| Attachment | Content-Type | Size |
|---|---|---|
| v1-PG14-0001-Use-the-join-clause-s-collation-for-Memoize-cache-key.patch | text/x-patch | 811 bytes |
| v1-PG15-0001-Use-the-join-clause-s-collation-for-Memoize-cache-key.patch | text/x-patch | 776 bytes |
| v1-PG16-0001-Use-the-join-clause-s-collation-for-Memoize-cache-key.patch | text/x-patch | 776 bytes |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bharath Rupireddy | 2026-10-09 17:44:21 | Re: Parallel autovacuum: DROP DATABASE WITH (FORCE) fails on the parallel workers |
| Previous Message | Rui Zhao | 2026-10-09 17:32:30 | Re: fix more casting away of qualifiers |