On 23.02.2011 07:20, Kevin Grittner wrote:
> Dan Ports wrote:
>
>> The obvious solution to me is to just keep the lock on both the old
>> and new page.
>
> That's the creative thinking I was failing to do. Keeping the old
> lock will generate some false positives, but it will be rare and
> those don't compromise correctness -- they just carry the cost of
> starting the transaction over.
Sounds reasonable, but let me throw in another idea while we're at it:
if there's a lock on the index page we're about to delete, we could just
choose to not delete it. The next vacuum will pick it up. Presumably it
will happen rarely, so index bloat won't be an issue.
>> I was going to bemoan the extra complexity this would add -- but
>> actually, couldn't we just replace PredicateLockPageCombine with a
>> call to PredicateLockPageSplit since they'd now do the same thing?
>
> I'd be inclined to leave the external interface alone, in case we
> conceive of an even better implementation.
Agreed.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
