Re: Improving replay of XLOG_BTREE_VACUUM records - Mailing list pgsql-hackers

From Vladimir Borodin
Subject Re: Improving replay of XLOG_BTREE_VACUUM records
Date
Msg-id A3444F84-3591-4382-8618-61103FD7DB50@simply.name
Whole thread Raw
In response to Re: Improving replay of XLOG_BTREE_VACUUM records  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: Improving replay of XLOG_BTREE_VACUUM records
List pgsql-hackers

10 марта 2016 г., в 14:38, Simon Riggs <simon@2ndquadrant.com> написал(а):

On 10 March 2016 at 09:22, Michael Paquier <michael.paquier@gmail.com> wrote:
On Thu, Mar 10, 2016 at 10:00 AM, Vladimir Borodin <root@simply.name> wrote:
> 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.

This makes sense. Let's not reject this patch yet if the alternative
approach is not committed.

I attach 2 patches.

avoid_pin_scan_always.v1.patch 
Takes the approach that we generate the same WAL records as in 9.5, we just choose not to do anything with that information. This is possible because we don't care anymore whether it is toast or other relations. So it effectively reverts parts of the earlier patch.
This could be easily back-patched more easily.

toast_recheck.v1.patch
Adds recheck code for toast access. I'm not certain this is necessary, but here it is. No problems found with it.

JFYI, I’m preparing the stand to reproduce the initial problem and I hope to finish testing this week.


--
Simon Riggs                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
<avoid_pin_scan_always.v1.patch><toast_recheck.v1.patch>


--
May the force be with you…

pgsql-hackers by date:

Previous
From: David Steele
Date:
Subject: Re: [PATCH] we have added support for box type in SP-GiST index
Next
From: David Steele
Date:
Subject: Re: dealing with extension dependencies that aren't quite 'e'