Re: SSI bug?

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: drkp(at)csail(dot)mit(dot)edu, yamt(at)mwd(dot)biglobe(dot)ne(dot)jp, pgsql-hackers(at)postgresql(dot)org
Subject: Re: SSI bug?
Date: 2011-02-24 17:10:58
Message-ID: 4D669122.80904@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Yeb Havinga 2011-02-24 17:14:13 Re: pg_basebackup and wal streaming
Previous Message Andrew Dunstan 2011-02-24 16:40:59 Re: wCTE: about the name of the feature