Re: Re: GiST optimizing memmoves in gistplacetopage for fixed-size updates [PoC]

Thank you, Amit.

Currently, if WAL reconstruct page in another order it won't be a problem.
How can I check that it works? Would it be sufficient if I kill 9 backend
and postmaster after commit and it will start normally executing select
queries after restart?

I'll make a patch with missing spaces later. I also found some more missing
spaces in PageIndexTupleOverwrite call and typo in comments ("on-place").

Best regards, Andrey Borodin, Octonica & Ural Federal University.

2016-07-04 18:58 GMT+05:00 Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>:

> On Mon, Jul 4, 2016 at 4:52 PM, Andrew Borodin <borodin(at)octonica(dot)com>
> wrote:
> > Here is a patch with corrections from Alexander Korotkov.
> > My tests, check and check-world show no problems against Ubuntu LTS 14
> x64 VM.
> >
> >
>
> - PageIndexTupleDelete(page, oldoffnum);
> - gistfillbuffer(page, itup, ntup, InvalidOffsetNumber);
> + {
> + /*if we have just one tuple to update we replace it on-place on page*/
> + if(ntup == 1)
> + {
> + PageIndexTupleOverwrite(page,oldoffnum,*itup);
> + }
> + else
> + {
> + /*this corner case is here to support mix calls case (see comment
> above)*/
> + PageIndexTupleDelete(page, oldoffnum);
> + gistfillbuffer(page, itup, ntup, InvalidOffsetNumber);
> + }
>
>
> Here, you have changed the way tuple is added on a page, but still the
> WAL record is same as before. I think WAL replay should perform the
> action in a same way as we have done when original operation is
> performed. If not, then it can change the organization of page which
> might lead to failure in replay of consecutive WAL records.
>
> + /*if we have just one tuple to update we replace it on-place on page*/
>
> In comments, we always leave a space both in the beginning and at the
> end of a comment. See comments in nearby code.
>
>
> --
> With Regards,
> Amit Kapila.
> EnterpriseDB: http://www.enterprisedb.com
>