Re: CURRENT OF causes an error when IndexOnlyScan is used
Yugo Nagata <nagata@sraoss.co.jp>
From: Yugo Nagata <nagata@sraoss.co.jp>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Anastasia Lubennikova <a.lubennikova@postgrespro.ru>,
pgsql-hackers@lists.postgresql.org
Date: 2018-03-15T08:04:13Z
Lists: pgsql-hackers
On Mon, 12 Mar 2018 13:56:24 -0400 Tom Lane <tgl@sss.pgh.pa.us> wrote: > Anastasia Lubennikova <a.lubennikova@postgrespro.ru> writes: > > [ return_heaptuple_in_btree_indexonlyscan_v2.patch ] > > I took a quick look at this, but I'm concerned about a couple of points: > > 1. What's the performance penalty of forming (and then deforming) the > added heap tuple? We'd be paying it for every index-only scan, whether > or not any CURRENT OF fetch ever happened. > > 2. The constructed tuple provides tableoid and ctid all right, but it'd > still have garbage values for other system columns. As the code stands, > we will properly error out if some attempt is made to fetch any of those > other columns, but with this change we'd just return the garbage. This > is a minor point, but it doesn't seem negligible to me; it might've been > hard to identify the bug at hand if we'd not had the cross-check of not > building a heap tuple. In addition, this patch fixes only nbtree indexes, but the simillar problem will occur also on GIST indexes which support index-only scan. If we resolve this bug by fixing index access methods, I think we need to fix all existing indexes that support index-only scan and also describe the specification in the documents, comments, or README, etc. for future indexes. > At this point Yugo-san's original patch is starting to look more > attractive. It's still ugly, but at least it's not imposing a performance > cost on unrelated queries. I would like to elaborate my patch if needed and possible. Any suggestion would be appriciated. Thanks, > > regards, tom lane -- Yugo Nagata <nagata@sraoss.co.jp>
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