Message-ID: <4D669122.80904@enterprisedb.com>
Date: Thu, 24 Feb 2011 19:10:58 +0200
From: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; fi-FI;
	rv:1.9.1.16) Gecko/20101226 Icedove/3.0.11
MIME-Version: 1.0
To: Kevin Grittner <Kevin.Grittner@wicourts.gov>
CC: drkp@csail.mit.edu, yamt@mwd.biglobe.ne.jp, pgsql-hackers@postgresql.org
Subject: Re: SSI bug?
References: <4D6444B9020000250003AE98@gw.wicourts.gov>
In-Reply-To: <4D6444B9020000250003AE98@gw.wicourts.gov>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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