Re: GSoC on WAL-logging hash indexes

On 03/07/2014 03:48 PM, Robert Haas wrote:
> On Fri, Mar 7, 2014 at 4:34 AM, Heikki Linnakangas
> <hlinnakangas(at)vmware(dot)com> wrote:
>> >Hmm. You suggested ensuring that a scan always has at least a pin, and split
>> >takes a vacuum-lock. That ought to work. There's no need for the more
>> >complicated maneuvers you described, ISTM that you can just replace the
>> >heavy-weight share lock with holding a pin on the primary page of the
>> >bucket, and an exclusive lock with a vacuum-lock. Note that
>> >_hash_expandtable already takes the exclusive lock conditionally, ie. if it
>> >doesn't get the lock immediately it just gives up. We could do the same with
>> >the cleanup lock.
> We could try that. I assume you mean do*just* what you describe
> here, without the split-in-progress or moved-by-split flags I
> suggested.

Yep.

> The only issue I see with that is that instead of everyone
> piling up on the heavyweight lock, a wait which is interruptible,
> they'd all pile up on the buffer content lwlock, a wait which isn't.
> And splitting a bucket can involve an arbitrary number of I/O
> operations, so that's kind of unappealing. Even checkpoints would be
> blocked until the bucket split completed, which seems unfortunate.

Hmm. I doubt that's a big deal in practice, although I agree it's a bit
ugly.

Once we solve the crash-safety of splits, we actually have the option of
doing the split in many small steps, even when there's no crash
involved. You could for example grab the vacuum-lock, move all the
tuples in the first 5 pages, and then release the lock to give other
backends that are queued up a chance to do their scans/insertions. Then
re-acquire the lock, and continue where you left. Or just bail out and
let the next vacuum or insertion to finish it later.

- Heikki