| From: | Heikki Linnakangas <heikki(dot)linnakangas(at)iki(dot)fi> |
|---|---|
| To: | pgsql-committers(at)lists(dot)postgresql(dot)org |
| Subject: | pgsql: Fix confusion on different kinds of slots in IndexOnlyScans. |
| Date: | 2019-06-06 07:07:11 |
| Message-ID: | E1hYmUR-0002MI-71@gemulon.postgresql.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-committers |
Fix confusion on different kinds of slots in IndexOnlyScans.
We used the same slot to store a tuple from the index, and to store a
tuple from the table. That's not OK. It worked with the heap, because
heapam_getnextslot() stores a HeapTuple to the slot, and doesn't care how
large the tts_values/nulls arrays are. But when I played with a toy table
AM implementation that used a virtual tuple, it caused memory overruns.
In the passing, tidy up comments on the ioss_PscanLen fields.
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/cd96389d713787b025c84869ba417c6f2f008a86
Modified Files
--------------
src/backend/executor/nodeIndexonlyscan.c | 16 +++++++++++++---
src/include/nodes/execnodes.h | 6 ++++--
2 files changed, 17 insertions(+), 5 deletions(-)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2019-06-06 08:28:36 | pgsql: pg_waldump: Fix invalid option handling |
| Previous Message | David Rowley | 2019-06-06 00:37:11 | pgsql: Docs: concurrent builds of partitioned indexes are not supported |