| From: | John Naylor <john(dot)naylor(at)enterprisedb(dot)com> |
|---|---|
| To: | Floris Van Nee <florisvannee(at)optiver(dot)com> |
| Cc: | Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: non-HOT update not looking at FSM for large tuple update |
| Date: | 2021-03-09 17:25:14 |
| Message-ID: | CAFBsxsGTBGgW33SyBf9=UkfUrWwYgD3azF9jEP9X9H8V1nkV+Q@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Mar 9, 2021 at 9:40 AM Floris Van Nee <florisvannee(at)optiver(dot)com>
wrote:
>
> Hi,
>
> >
> > This patch fails to consider that len may be bigger than
MaxHeapTupleSize *
> > 0.98, which in this case triggers a reproducable
> > PANIC:
>
> Good catch! I've adapted the patch with your suggested fix.
Thank you both for testing and for the updated patch. It seems we should
add a regression test, but it's not clear which file it belongs in.
Possibly insert.sql?
> > One different question I have, though, is why we can't "just" teach
vacuum
> > to clean up trailing unused line pointers. As in, can't we trim the
line pointer
> > array when vacuum detects that the trailing line pointers on the page
are all
> > unused?
That seems like the proper fix, and I see you've started a thread for that.
I don't think that change in behavior would be backpatchable, but patch
here might have a chance at that.
--
John Naylor
EDB: http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | John Naylor | 2021-03-09 17:38:57 | Re: non-HOT update not looking at FSM for large tuple update |
| Previous Message | Bruce Momjian | 2021-03-09 17:20:49 | Re: WIP: document the hook system |