|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|
|Views:||Raw Message | Whole Thread | Download mbox|
On Thu, Mar 29, 2018 at 11:39 AM, Michael Paquier <michael(at)paquier(dot)xyz>
> 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
on the latest master for review. I will move the patch to next commitfest
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
dependency from HeapTuple in . Based on the output of that thread, these
patches needs an update.
|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|