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.linnakan...@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.
> 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.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
