Re: old_snapshot_threshold's interaction with hash index

<div dir="ltr">On Fri, May 6, 2016 at 12:45 AM, Amit Kapila <<a
href="mailto:amit.kapila16@gmail.com">amit.kapila16@gmail.com</a>>wrote:<br />> On Wed, May 4, 2016 at 7:48 PM,
KevinGrittner <<a href="mailto:kgrittn@gmail.com">kgrittn@gmail.com</a>> wrote:<br />>> On Tue, May 3, 2016
at11:48 AM, Robert Haas <<a href="mailto:robertmhaas@gmail.com">robertmhaas@gmail.com</a>> wrote:<br
/>>><br/>>>> OK, I see now: the basic idea here is that we can't prune based on the<br />>>>
newerXID unless the page LSN is guaranteed to advance whenever data<br />>>> is removed.  Currently, we
attemptto limit bloat in non-unlogged,<br />>>> non-catalog tables.  You're saying we can instead attempt to
limit<br/>>>> bloat only in non-unlogged, non-catalog tables without hash indexes,<br />>>> and that
willfix this issue.  Am I right?<br />>><br />>> As a first cut, something like the attached.<br />><br
/>>Patch looks good to me.  I have done some testing with hash and<br />> btree indexes and it works as
expected.<br/><br />Pushed with the addition of a paragraph to the docs regarding this<br />and some other situations
wherepeople have been unclear about what<br />to expect.<br /><br />--<br />Kevin Grittner<br />EDB: <a
href="http://www.enterprisedb.com">http://www.enterprisedb.com</a><br/>The Enterprise PostgreSQL Company<br /><br
/></div>