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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-hackers by date

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