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