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.linnakangas@enterprisedb.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
