Re: snapshot too old, configured by time - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: snapshot too old, configured by time
Date
Msg-id CACjxUsOrZPTmzL-OcvYsX4VC0tMFD45kWZ=qXN28GPv1XinhqQ@mail.gmail.com
Whole thread Raw
In response to Re: snapshot too old, configured by time  (Peter Geoghegan <pg@heroku.com>)
Responses Re: snapshot too old, configured by time  (Peter Geoghegan <pg@heroku.com>)
List pgsql-hackers
On Thu, Apr 7, 2016 at 6:12 PM, Peter Geoghegan <pg@heroku.com> wrote:

> I think that there is a good argument in favor of this patch that you
> may have failed to make yourself, which is: it limits bloat in a way
> that's analogous to how RecentGlobalDataXmin can do so for logical
> decoding (i.e. where wal_level = logical, and RecentGlobalXmin and
> RecentGlobalDataXmin could actually differ). Therefore, it benefits to
> a significant degree from the testing that Andres did to make sure
> logical decoding doesn't cause excessive bloat when RecentGlobalXmin
> is pinned to make historic MVCC catalog snapshots work (he did so at
> my insistence at the time; pruning turned out to be very important for
> many common workloads, and Andres got that right). I can't really
> imagine a way that what you have here could be any less effective than
> what Andres did for logical decoding. This is reassuring, since that
> mechanism has to be pretty well battle-hardened by now.

Interesting.  I had not noticed that relationship.

Anyway, pushed as two patches -- the no-op patch to create the "forced
choice" on whether to do the test at each BufferGetPage point, and the
actual feature.

Sadly, I forgot to include the reviewer information when writing the
commit messages.  :-(

-- 
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: [COMMITTERS] pgsql: CREATE INDEX ... INCLUDING (column[, ...])
Next
From: Peter Geoghegan
Date:
Subject: Re: snapshot too old, configured by time