Re: Pluggable Storage - Andres's take

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: Pluggable Storage - Andres's take
Дата
Msg-id e71c4da4-3e82-cc4f-32cc-ede387fac8b0@iki.fi
обсуждение исходный текст
Ответ на Re: Pluggable Storage - Andres's take  (Andres Freund <andres@anarazel.de>)
Ответы Re: Pluggable Storage - Andres's take  (Rafia Sabih <rafia.pghackers@gmail.com>)
Re: Pluggable Storage - Andres's take  (Ashwin Agrawal <aagrawal@pivotal.io>)
Список pgsql-hackers
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.

>> Attached is a patch with the toy implementation I used to test this. I'm not
>> suggesting we should commit that - although feel free to do that if you
>> think it's useful - but it shows how I bumped into these issues.
> 
> Hm, probably not a bad idea to include something like it. It seems like
> we kinda would need non-stub implementation of more functions for it to
> test much / and to serve as an example.  I'm mildy inclined to just do
> it via zheap / externally, but I'm not quite sure that's good enough.

Works for me.

>> +static Size
>> +toyam_parallelscan_estimate(Relation rel)
>> +{
>> +    ereport(ERROR,
>> +            (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
>> +             errmsg("function %s not implemented yet", __func__)));
>> +}
> 
> The other stubbed functions seem like we should require them, but I
> wonder if we should make the parallel stuff optional?

Yeah, that would be good. I would assume it to be optional.

- Heikki

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: David Steele
Дата:
Сообщение: Re: proposal: plpgsql pragma statement
Следующее
От: Zhichao Liu
Дата:
Сообщение: GSOC 2019 proposal 'WAL-G safety features'