| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Srinath Reddy Sadipiralla <srinath2133(at)gmail(dot)com> |
| Cc: | Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, Imran Zaheer <imran(dot)zhir(at)gmail(dot)com>, Alexander Lakhin <exclusion(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>, Konstantin Knizhnik <knizhnik(at)garret(dot)ru> |
| Subject: | Re: BUG #19519: REPACK can fail due to missing chunk for toast value |
| Date: | 2026-07-08 01:10:11 |
| Message-ID: | ak2jc7mIhcMDkm-k@paquier.xyz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Wed, Jul 08, 2026 at 07:15:16AM +0900, Michael Paquier wrote:
> One thing that I still don't like much in the patch as written is my
> use of a missing_ok argument, which feels super confusing as it
> applies only to the underlying external TOAST, if the relation has
> any. I'd be tempted to rewrite this portion of the patch with a
> uint32 flags. Even if we assign one value for now (say MISSING_TOAST,
> MISSING_TOAST_OK or whatever), it would allow more flexibility on ABI
> grounds if we want more like states in the future across this portion
> of the stack. Again, I strongly doubt that we will be able to
> backpatch any of that.
A couple of extra notes while I do not forget about that stuff.. The
patch may be better split into two if we go with this approach, as the
index build and rewrite paths require different solutions:
- One for the rewrite path. It makes little sense to do any kind of
aggressive early detoasting because it may be wasteful due to the
tuple rewrites that update their data with only copies by reference
(main relation tuple is rewritten, reuses the same external TOAST
tuple). For workloads where UPDATEs do not touch the TOASTed
attributes, that would be a waste.
- One for the index build path, which is actually too aggressive with
its early detoasting, now that I think about it. There should be no
need to perform a detoast for anything else than the attributes that
are used in the index definition or the attributes that are used in
index expressions. So as written this patch would lead to a
regression.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ewan Young | 2026-07-08 06:27:55 | Re: BUG #19545: Integer truncation of `GinTuple.keylen` causes out-of-bounds read in parallel GIN index build |
| Previous Message | Thom Brown | 2026-07-08 00:42:28 | Re: EXPLAIN (VERBOSE) fails with for JSON_ARRAYAGG/JSON_OBJECTAGG + window function |