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
> 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?
In response to
pgsql-hackers by date
|Next:||From: Heikki Linnakangas||Date: 2012-02-29 14:40:11|
|Subject: Re: 16-bit page checksums for 9.2|
|Previous:||From: Pavel Stehule||Date: 2012-02-29 13:37:48|
|Subject: Re: review: CHECK FUNCTION statement|