Re: SSI rw-conflicts and 2PC
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
From: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
To: Jeff Davis <pgsql@j-davis.com>
Cc: Dan Ports <drkp@csail.mit.edu>, Kevin Grittner <Kevin.Grittner@wicourts.gov>, pgsql-hackers@postgresql.org
Date: 2012-02-29T13:56:43Z
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.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