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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2012-02-22 23:38:30 Re: pg_upgrade --logfile option documentation
Previous Message Tom Lane 2012-02-22 23:30:37 Re: leakproof