Yugo Nagata <nag...@sraoss.co.jp> writes: > On Mon, 12 Mar 2018 13:56:24 -0400 > Tom Lane <t...@sss.pgh.pa.us> wrote: >> I took a quick look at this, but I'm concerned about a couple of points:
> 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. Yeah, that's a pretty good point. >> 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. I don't think there's much else to be done so far as the IndexOnlyScan case is concerned. However, I notice that somebody's made search_plan_tree accept ForeignScanState and CustomScanState as possible matches for WHERE CURRENT OF, and I find that rather troubling. It seems likely to me that both of those would have the same problem as IndexOnlyScans, ie whatever they're returning is probably a virtual tuple without any ctid field. So we'd get the same unfriendly failure as you complained of originally. I wonder whether it wouldn't be a good idea to provide a way for an FDW or CustomScan provider to return a TID, or at least give a more polite FEATURE_NOT_SUPPORTED error than what happens now. However, that seems more like a new feature than a bug fix; certainly any extension of those APIs is something we'd not back-patch. In the meantime, we could fix execCurrent.c so that it throws FEATURE_NOT_SUPPORTED rather than the current failure if the slot it's looking at doesn't contain a physical tuple. regards, tom lane