On Sun, Aug 5, 2018 at 7:48 PM Andres Freund <andres@anarazel.de> wrote:
Hi,
I'm currently in the process of rebasing zheap onto the pluggable storage work. The goal, which seems to work surprisingly well, is to find issues that the current pluggable storage patch doesn't yet deal with. I plan to push a tree including a lot of fixes and improvements soon.
Sorry for coming late to this thread.
That's good. Did you find any problems in porting zheap into pluggable
storage? Does it needs any API changes or new API requirement?
On 2018-08-03 12:35:50 +1000, Haribabu Kommi wrote: > while investing the crash, I observed that it is due to the lot of FIXME's > in > the code. So I just fixed minimal changes and looking into correcting > the FIXME's first. > > One thing I observed is lack relation pointer is leading to crash in the > flow of EvalPlan* functions, because all ROW_MARK types doesn't > contains relation pointer. > > will continue to check all FIXME fixes.
Thanks.
I fixed some of the Isolation test problems. All the issues are related to
EPQ slot handling. Still more needs to be fixed.
Does the new TupleTableSlot abstraction patches has fixed any of these
issues in the recent thread [1]? so that I can look into the change of FDW API
to return slot instead of tuple.
> > - COPY's multi_insert path should probably deal with a bunch of slots, > > rather than forming HeapTuples > > > > Implemented supporting of slots in the copy multi insert path.
Cool. I've not yet looked at it, but I plan to do so soon. Will have to rebase over the other copy changes first :(
OK. Understood. There are many changes in the COPY flow conflicts
with my changes. Please let me know once you done the rebase, I can
