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
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 |