Re: Improving replay of XLOG_BTREE_VACUUM records

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: Vladimir Borodin <root(at)simply(dot)name>, Simon Riggs <simon(at)2ndquadrant(dot)com>, David Steele <david(at)pgmasters(dot)net>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Improving replay of XLOG_BTREE_VACUUM records
Date: 2016-03-10 11:38:22
Views: Raw Message | Whole Thread | Download mbox
Lists: pgsql-hackers

On 10 March 2016 at 09:22, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>

> On Thu, Mar 10, 2016 at 10:00 AM, Vladimir Borodin <root(at)simply(dot)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.

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.

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

Simon Riggs
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Attachment Content-Type Size
avoid_pin_scan_always.v1.patch application/octet-stream 6.1 KB
toast_recheck.v1.patch application/octet-stream 2.9 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2016-03-10 11:42:30 Re: Parallel Aggregate
Previous Message Kyotaro HORIGUCHI 2016-03-10 11:30:51 Re: psql completion for ids in multibyte string