|From:||Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru>|
|To:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp>|
|Subject:||Re: CURRENT OF causes an error when IndexOnlyScan is used|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
01.02.2018 05:12, Tom Lane:
> Yugo Nagata <nagata(at)sraoss(dot)co(dot)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"
where we can store long (and even TOASTed) attributes in indextuple.
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
|Next Message||Ildus Kurbangaliev||2018-02-19 14:38:54||Re: autovacuum: change priority of the vacuumed tables|
|Previous Message||Ildus Kurbangaliev||2018-02-19 14:19:15||Re: Prefix operator for text and spgist support|