Re: [HACKERS] Pluggable storage

From: Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: David Steele <david(at)pgmasters(dot)net>, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, Robert Haas <robertmhaas(at)gmail(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] Pluggable storage
Date: 2018-03-29 05:54:34
Message-ID: CAJrrPGeVmumNZK9zgL7JqEAKVS0PO0VsE+-ADdU0w1woi4EqTw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Mar 29, 2018 at 11:39 AM, Michael Paquier <michael(at)paquier(dot)xyz>
wrote:

> On Wed, Mar 28, 2018 at 12:23:56PM -0400, David Steele wrote:
> > I think this entry should be moved the the next CF. I'll do that
> > tomorrow unless there are objections.
>
> Instead of moving things to the next CF by default, perhaps it would
> make more sense to mark things as reviewed with feedback as this is the
> last CF? There is a 5-month gap between this commit fest and the next
> one, I am getting afraid of flooding the beginning of v12 development
> cycle with entries which keep rotting over time.

Yes, especially I observed many of the "ready of committer" patches are just
moving from past commitfests without a review from committer.

> If the author(s) claim
> that they will be able to work on it, then that's of course fine.
>

But in this case, I am planning to work on it. Here I attached rebased
patches
on the latest master for review. I will move the patch to next commitfest
in the
commitfest app.

The attached patches doesn't work with recent JIT changes that are gone in
master, because of removal many of the members from TupleTableSlot structure
and it effects the JIT tuple deforming. This is yet to fixed.

There is an another thread proposed by Andres in abstracting the
TupleTableslot
dependency from HeapTuple in [1]. Based on the output of that thread, these
patches needs an update.

[1] -
https://www.postgresql.org/message-id/20180220224318.gw4oe5jadhpmcdnm%40alap3.anarazel.de

Regards,
Hari Babu
Fujitsu Australia

Attachment Content-Type Size
0013-Using-access-method-syntax-addition-to-create-table.patch application/octet-stream 18.4 KB
0014-ExecARUpdateTriggers-is-updated-to-accept-slot-inste.patch application/octet-stream 6.5 KB
0001-Change-Create-Access-method-to-include-table-handler.patch application/octet-stream 9.1 KB
0002-Table-AM-API-init-functions.patch application/octet-stream 10.0 KB
0003-Adding-tableam-hanlder-to-relation-structure.patch application/octet-stream 7.1 KB
0004-Adding-tuple-visibility-functions-to-table-AM.patch application/octet-stream 53.0 KB
0005-slot-hooks-are-added-to-table-AM.patch application/octet-stream 67.1 KB
0006-Tuple-Insert-API-is-added-to-table-AM.patch application/octet-stream 93.4 KB
0007-Scan-functions-are-added-to-table-AM.patch application/octet-stream 104.0 KB
0008-Remove-HeapScanDesc-usage-outside-heap.patch application/octet-stream 97.4 KB
0009-BulkInsertState-is-added-into-table-AM.patch application/octet-stream 10.7 KB
0010-table-rewrite-functionality.patch application/octet-stream 11.1 KB
0011-Improve-tuple-locking-interface.patch application/octet-stream 46.6 KB
0012-Table-AM-shared-memory-API.patch application/octet-stream 6.5 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Craig Ringer 2018-03-29 05:58:45 Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS
Previous Message Masahiko Sawada 2018-03-29 05:48:40 Re: pg_class.reltuples of brin indexes