Re: Minmax indexes

From: Claudio Freire <klaussfreire(at)gmail(dot)com>
To: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Nicolas Barbier <nicolas(dot)barbier(at)gmail(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Minmax indexes
Date: 2014-08-10 17:43:17
Message-ID: CAGTBQpY2idBMSciCuskwcmNbymnY0OKuhm5B4jTT2azWCEk4BQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Aug 8, 2014 at 6:01 AM, Heikki Linnakangas
<hlinnakangas(at)vmware(dot)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.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Davis 2014-08-10 20:50:16 Re: 9.5: Better memory accounting, towards memory-bounded HashAgg
Previous Message Fujii Masao 2014-08-10 16:31:27 Re: Support for N synchronous standby servers