Skip site navigation (1) Skip section navigation (2)

Re: SSI rw-conflicts and 2PC

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Dan Ports <drkp(at)csail(dot)mit(dot)edu>
Cc: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: SSI rw-conflicts and 2PC
Date: 2012-02-22 23:36:48
Message-ID: 1329953808.5627.35.camel@sussancws0025 (view raw or flat)
Thread:
Lists: pgsql-hackers
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
> > >> 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


In response to

Responses

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2012-02-22 23:38:30
Subject: Re: pg_upgrade --logfile option documentation
Previous:From: Tom LaneDate: 2012-02-22 23:30:37
Subject: Re: leakproof

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group