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.
>
> Dan, could you post such a patch, please?
Sure. See attached.
> Should we add anything to the docs to warn people that if they crash
> with serializable prepared transactions pending, they will see this
> behavior until the prepared transactions are either committed or
> rolled back, either by the transaction manager or through manual
> intervention?
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.
This semes like it'd be especially useful for prepared transactions. We
can generally pick the transaction to abort to ensure the safe retry
property -- if that transaction is immediately retried, it won't
fail with the same conflict -- but we can't always guarantee that when
prepared transactions are involved. And prepared transactions already
have a convenient, user-visible ID we can report.
Dan
--
Dan R. K. Ports MIT CSAIL http://drkp.net/