Postgres Pro
Downloads
Home   >   mailing lists

Re: [HACKERS] Pluggable storage - Mailing list pgsql-hackers

From Haribabu Kommi
Subject Re: [HACKERS] Pluggable storage
Date
Msg-id CAJrrPGeVmumNZK9zgL7JqEAKVS0PO0VsE+-ADdU0w1woi4EqTw@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Pluggable storage  (Michael Paquier <michael@paquier.xyz>)
Responses Re: [HACKERS] Pluggable storage  (Haribabu Kommi <kommi.haribabu@gmail.com>)
List pgsql-hackers
Tree view

On Thu, Mar 29, 2018 at 11:39 AM, Michael Paquier <michael@paquier.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.


Regards,
Hari Babu
Fujitsu Australia
Attachment

pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: pg_class.reltuples of brin indexes
Next
From: Craig Ringer
Date:
Subject: Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS