Re: old_snapshot_threshold's interaction with hash index

From: Kevin Grittner <kgrittn(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: old_snapshot_threshold's interaction with hash index
Date: 2016-05-03 16:56:06
Message-ID: CACjxUsNFsPoTbPYXxu--Td6ym4Xi=3vprOm4HrePji+H-0LLEg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, May 3, 2016 at 11:48 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> OK, I see now: the basic idea here is that we can't prune based on the
> newer XID unless the page LSN is guaranteed to advance whenever data
> is removed. Currently, we attempt to limit bloat in non-unlogged,
> non-catalog tables. You're saying we can instead attempt to limit
> bloat only in non-unlogged, non-catalog tables without hash indexes,
> and that will fix this issue. Am I right?

Right.

I was wondering whether there might be other avenues to the same
end, but that is the most obvious fix. I'm hesitant to raise the
alternatives because people seem to have entered "panic mode", at
which point alternatives always look scary.

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2016-05-03 16:58:12 Re: what to revert
Previous Message Robert Haas 2016-05-03 16:48:18 Re: old_snapshot_threshold's interaction with hash index