Re: Minmax indexes
Claudio Freire <klaussfreire@gmail.com>
From: Claudio Freire <klaussfreire@gmail.com>
To: Heikki Linnakangas <hlinnakangas@vmware.com>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>,
Simon Riggs <simon@2ndquadrant.com>, Robert Haas <robertmhaas@gmail.com>,
Nicolas Barbier <nicolas.barbier@gmail.com>,
Josh Berkus <josh@agliodbs.com>, Andres Freund <andres@2ndquadrant.com>,
Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2014-08-10T17:43:17Z
Lists: pgsql-hackers
On Fri, Aug 8, 2014 at 6:01 AM, Heikki Linnakangas <hlinnakangas@vmware.com> wrote: > It's possible that two backends arrive at phase 3 at the same time, with > different values. For example, backend A wants to update the minimum to > contain 10, and and backend B wants to update it to 5. Now, if backend B > gets to update the tuple first, to 5, backend A will update the tuple to 10 > when it gets the lock, which is wrong. > > The simplest solution would be to get the buffer lock in exclusive mode to > begin with, so that you don't need to release it between steps 2 and 5. That > might be a significant hit on concurrency, though, when most of the > insertions don't in fact have to update the value. Another idea is to > re-check the updated values after acquiring the lock in exclusive mode, to > see if they match the previous values. No, the simplest solution is to re-check the bounds after acquiring the exclusive lock. So instead of doing the addValue with share lock, do a consistency check first, and if it's not consistent, do the addValue with exclusive lock.
Commits
-
Refactor per-page logic common to all redo routines to a new function.
- f8f4227976a2 9.5.0 cited
-
Reduce use of heavyweight locking inside hash AM.
- 76837c1507cb 9.3.0 cited
-
Scan the buffer pool just once, not once per fork, during relation drop.
- ece01aae4792 9.2.0 cited
-
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
- 9e2a87b62db8 7.1.1 cited