Re: SSI and 2PC

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: <pgsql-hackers(at)postgresql(dot)org>
Cc: "Dan Ports" <drkp(at)csail(dot)mit(dot)edu>, "Heikki Linnakangas" <heikki(dot)linnakangas(at)enterprisedb(dot)com>, "Jeff Davis" <pgsql(at)j-davis(dot)com>
Subject: Re: SSI and 2PC
Date: 2011-01-10 17:50:16
Message-ID: 4D2AF27802000025000391DF@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
> "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
>
>> In going back through old emails to see what issues might have
>> been raised but not yet addressed for the SSI patch, I found the
>> subject issue described in a review by Jeff Davis here:
>>
>> http://archives.postgresql.org/pgsql-hackers/2010-10/msg01159.php
>
> After reviewing the docs and testing things, I'm convinced that
> more work is needed. Because the transaction's writes aren't
> visible until COMMIT PREPARED is run, and write-write conflicts
> are still causing serialization failures after PREPARE
> TRANSACTION, some of the work being done for SSI on PREPARE
> TRANSACTION needs to be moved to COMMIT PREPARED.

I'm now also convinced that Jeff is right in his assessment that
when a transaction is prepared, information about predicate locks
and conflicts with other prepared transactions must be persisted
somewhere. (Jeff referred to a "2PC state file".)

I'm trying not to panic here, but I haven't looked at 2PC before
yesterday and am just dipping into the code to support it, and time
is short. Can anyone give me a pointer to anything I should read
before I dig through the 2PC code, which might accelerate this?

-Kevin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2011-01-10 17:58:13 Re: system views for walsender activity
Previous Message David Fetter 2011-01-10 17:48:45 Re: SSI patch version 8