Re: Improving replay of XLOG_BTREE_VACUUM records

> 10 марта 2016 г., в 11:50, Simon Riggs <simon(at)2ndquadrant(dot)com> написал(а):
>
> On 10 March 2016 at 06:27, Michael Paquier <michael(dot)paquier(at)gmail(dot)com <mailto:michael(dot)paquier(at)gmail(dot)com>> wrote:
> On Thu, Mar 10, 2016 at 1:29 AM, David Steele <david(at)pgmasters(dot)net <mailto:david(at)pgmasters(dot)net>> wrote:
> > On 1/8/16 9:34 AM, Alvaro Herrera wrote:
> >> Simon Riggs wrote:
> >>>
> >>> On 8 January 2016 at 13:36, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com <mailto:alvherre(at)2ndquadrant(dot)com>>
> >>> wrote:
> >>>>
> >>>> I would agree except for the observation on toast indexes. I think
> >>>> that's an important enough use case that perhaps we should have both.
> >>>
> >>> The exclusion of toast indexes is something we can remove also, I have
> >>> recently discovered. When we access toast data we ignore MVCC, but we
> >>> still
> >>> have the toast pointer and chunkid to use for rechecking our scan
> >>> results.
> >>> So a later patch will add some rechecks.
> >>
> >> Ah, interesting, glad to hear. I take it you're pushing your patch
> >> soon, then?
> >
> > ISTM that this patch should be "returned with feedback" or "rejected" based
> > on the thread. I'm marking it "waiting for author" for the time being.
>
> I think that we are still waiting for some input from Simon here...
> Simon, are you going to finish wrapping up your other patch?
>
> Yes, I have done the research, so think patch should be rejected now.

Let’s do immediately after you will send a new version of your patch? Or even better after testing your patch? Don’t get me wrong, but rejecting my patch without tangible work on your patch may lead to forgiving about the problem before 9.6 freeze.

>
> Thanks to everyone for their input. It's good to have alternate approaches.
>
> --
> Simon Riggs http://www.2ndQuadrant.com/ <http://www.2ndquadrant.com/>
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--
May the force be with you…
https://simply.name