Re: Pluggable Storage - Andres's take - Mailing list pgsql-hackers

From Ashwin Agrawal
Subject Re: Pluggable Storage - Andres's take
Date
Msg-id CALfoeisMmdJfKHZK6ZJix9Q1vcigK4MgR5uYO2wzCP2rdYbhFQ@mail.gmail.com
Whole thread Raw
In response to Re: Pluggable Storage - Andres's take  (Heikki Linnakangas <hlinnaka@iki.fi>)
Responses Re: Pluggable Storage - Andres's take
List pgsql-hackers
On Tue, Apr 9, 2019 at 6:17 AM Heikki Linnakangas <hlinnaka@iki.fi> wrote:
On 08/04/2019 20:37, Andres Freund wrote:
> On 2019-04-08 15:34:46 +0300, Heikki Linnakangas wrote:
>> There's a little bug in index-only scan executor node, where it mixes up the
>> slots to hold a tuple from the index, and from the table. That doesn't cause
>> any ill effects if the AM uses TTSOpsHeapTuple, but with my toy AM, which
>> uses a virtual slot, it caused warnings like this from index-only scans:
>
> Hm. That's another one that I think I had fixed previously :(, and then
> concluded that it's not actually necessary for some reason. Your fix
> looks correct to me.  Do you want to commit it? Otherwise I'll look at
> it after rebasing zheap, and checking it with that.

I found another slot type confusion bug, while playing with zedstore. In
an Index Scan, if you have an ORDER BY key that needs to be rechecked,
so that it uses the reorder queue, then it will sometimes use the
reorder queue slot, and sometimes the table AM's slot, for the scan
slot. If they're not of the same type, you get an assertion:

TRAP: FailedAssertion("!(op->d.fetch.kind == slot->tts_ops)", File:
"execExprInterp.c", Line: 1905)

Attached is a test for this, again using the toy table AM, extended to
be able to test this. And a fix.

It seems the two patches from email [1] fixing slot confusion in Index Scans are pending to be committed.

pgsql-hackers by date:

Previous
From: Ashwin Agrawal
Date:
Subject: Re: Create TOAST table only if AM needs
Next
From: Ashwin Agrawal
Date:
Subject: Re: Pluggable Storage - Andres's take