| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Nikhil Kumar Veldanda <veldanda(dot)nikhilkumar17(at)gmail(dot)com> |
| Cc: | Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Some tests for TOAST, STORAGE MAIN/EXTENDED |
| Date: | 2026-01-26 00:33:09 |
| Message-ID: | aXa2RVzmwtxnlUC_@paquier.xyz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sun, Jan 25, 2026 at 09:46:51AM +0900, Michael Paquier wrote:
> On Fri, Jan 23, 2026 at 12:25:33AM -0800, Nikhil Kumar Veldanda wrote:
>> The `SELECT count(*) FROM :reltoastname` assertion is a bit brittle
>> for `STORAGE EXTENDED`: depending on the toast compression method /
>> effectiveness, the value may end up as >1 chunk, which would flip the
>> expected count(*) = 1. Prefer SELECT count(DISTINCT chunk_id) FROM
>> :reltoastname (or WHERE chunk_seq = 0) and adjust expected.
>
> Yeah, this suggestion sounds sensible and that would still notice what
> I was able to break.
I have settled down to the addition of a qual based on chunk_seq,
being consistent with the other test, at the end, then applied the
result as 168765e5d42b. Thanks for the suggestions, Nikhil.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Neil Chen | 2026-01-26 00:41:34 | Re: [PATCH] Avoid potential NULL dereference in LIKE/ILIKE with C locale |
| Previous Message | Jelte Fennema-Nio | 2026-01-25 23:38:15 | Re: Safer hash table initialization macro |