Re: CURRENT OF causes an error when IndexOnlyScan is used
Anastasia Lubennikova <a.lubennikova@postgrespro.ru>
From: Anastasia Lubennikova <a.lubennikova@postgrespro.ru>
To: Tom Lane <tgl@sss.pgh.pa.us>, Yugo Nagata <nagata@sraoss.co.jp>
Cc: pgsql-hackers@postgresql.org
Date: 2018-02-19T14:36:55Z
Lists: pgsql-hackers
Attachments
- return_heaptuple_in_btree_indexonlyscan_v1.patch (text/x-patch) patch v1
01.02.2018 05:12, Tom Lane: > Yugo Nagata <nagata@sraoss.co.jp> writes: >> I'm sorry the patch attached in the previous mail is broken and >> not raises a compile error. I attached the fixed patch. > This patch is almost certainly wrong: you can't assume that the scan-level > state matches the tuple we are currently processing at top level. Any > sort of delaying action, for instance a sort or materialize node in > between, would break it. > > We need to either fix this aspect: > >>> IndexOnlyScan returns a virtual tuple that doesn't have system >>> column, so we can not get ctid in the same way of other plans. I'd like to propose the patch that fixes the issue. We already have a way to return heaptuple from IndexOnlyScan, but it was not applied to b-tree for some reason. Attached patch solves the reported bug. Moreover, it will come in handy for "index with included attributes" feature [1], where we can store long (and even TOASTed) attributes in indextuple. [1] https://commitfest.postgresql.org/17/1350/ -- Anastasia Lubennikova Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
Commits
-
Fix WHERE CURRENT OF when the referenced cursor uses an index-only scan.
- 8f5ac440430a 11.0 landed
- ee7bf0fd9fa7 10.4 landed
- 7de7ddb27a86 9.5.13 landed
- 5b77c11da24a 9.3.23 landed
- 12d18b4870a2 9.6.9 landed
- 0a0721f84c40 9.4.18 landed