Skip site navigation (1) Skip section navigation (2)

Re: SSI rw-conflicts and 2PC

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: Dan Ports <drkp(at)csail(dot)mit(dot)edu>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: SSI rw-conflicts and 2PC
Date: 2012-02-29 13:56:43
Message-ID: 4F4E2E9B.1020702@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On 23.02.2012 01:36, Jeff Davis wrote:
> On Tue, 2012-02-14 at 19:32 -0500, Dan Ports wrote:
>> On Tue, Feb 14, 2012 at 09:27:58AM -0600, Kevin Grittner wrote:
>>> Heikki Linnakangas<heikki(dot)linnakangas(at)enterprisedb(dot)com>  wrote:
>>>> On 14.02.2012 04:57, Dan Ports wrote:
>>>>> The easiest answer would be to just treat every prepared
>>>>> transaction found during recovery as though it had a conflict in
>>>>> and out. This is roughly a one-line change, and it's certainly
>>>>> safe.
>
> +1.
>
> I don't even see this as much of a problem. Prepared transactions
> hanging around for arbitrary periods of time cause all kinds of problems
> already. Those using them need to be careful to resolve them quickly --
> and if there's a crash involved, I think it's reasonable to say they
> should be resolved before continuing normal online operations.

Committed this now. (sorry for the delay)

>> Hmm, it occurs to me if we have to abort a transaction due to
>> serialization failure involving a prepared transaction, we might want
>> to include the prepared transaction's gid in the errdetail.
>
> I like this idea.

+1. Anyone want to put together a patch?

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

In response to

Responses

pgsql-hackers by date

Next:From: Heikki LinnakangasDate: 2012-02-29 14:40:11
Subject: Re: 16-bit page checksums for 9.2
Previous:From: Pavel StehuleDate: 2012-02-29 13:37:48
Subject: Re: review: CHECK FUNCTION statement

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group