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.


  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to