Re: Pluggable Storage - Andres's take

From: Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Pluggable Storage - Andres's take
Date: 2018-10-16 02:59:21
Message-ID: CAJrrPGfJWp7N2fPb9MrFR8rkCQr2x8qiEX3K_zPp8V+z090iYg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Oct 9, 2018 at 1:46 PM Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>
wrote:

> On Wed, Oct 3, 2018 at 3:16 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
>
>> On 2018-09-27 20:03:58 -0700, Andres Freund wrote:
>> > On 2018-09-28 12:21:08 +1000, Haribabu Kommi wrote:
>> > > Here I attached further cleanup patches.
>> > > 1. Re-arrange the GUC variable
>> > > 2. Added a check function hook for default_table_access_method GUC
>> >
>> > Cool.
>> >
>> >
>> > > 3. Added a new hook validate_index. I tried to change the function
>> > > validate_index_heapscan to slotify, but that have many problems as it
>> > > is accessing some internals of the heapscandesc structure and
>> accessing
>> > > the buffer and etc.
>> >
>> > Oops, I also did that locally, in a way. I also made a validate a
>> > callback, as the validation logic is going to be specific to the AMs.
>> > Sorry for not pushing that up earlier. I'll try to do that soon,
>> > there's a fair amount of change.
>>
>> I've pushed an updated version, with a fair amount of pending changes,
>> and I hope all your pending (and not redundant, by our concurrent
>> development), patches merged.
>>
>
> Yes, All the patches are merged.
>
> There's currently 3 regression test failures, that I'll look into
>> tomorrow:
>> - partition_prune shows a few additional Heap Blocks: exact=1 lines. I'm
>> a bit confused as to why, but haven't really investigated yet.
>> - fast_default fails, because I've undone most of 7636e5c60fea83a9f3c,
>> I'll have to redo that in a different way.
>> - I occasionally see failures in aggregates.sql - I've not figured out
>> what's going on there.
>>
>
> I also observed the failure of aggregates.sql, will look into it.
>
>
>> Amit Khandekar said he'll publish a new version of the slot-abstraction
>> patch tomorrow, so I'll rebase it onto that ASAP.
>>
>
> OK.
> Here I attached two new API patches.
> 1. Set New Rel File node
> 2. Create Init fork
>

The above patches are having problem and while testing it leads to crash.
Sorry for not testing earlier. The index relation also creates the
NewRelFileNode,
because of moving that function as pluggable table access method, and for
Index relations, there is no tableam routine, thus it leads to crash.

So moving the storage creation methods as table access methods doesn't
work. we may need common access methods that are shared across both
table and index.

Regards,
Haribabu Kommi
Fujitsu Australia

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-10-16 03:01:12 Re: Large writable variables
Previous Message Bruce Momjian 2018-10-16 02:49:29 Re: Creating Certificates