Heikki Linnakangas wrote:
> On 23.02.2012 01:36, Jeff Davis wrote:
>> On Tue, 2012-02-14 at 19:32 -0500, Dan Ports wrote:
>>> 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 transa
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 wrote:
On 14.02.2012 04:57, Dan Ports wrote:
The easiest answer would be to just treat every prepared
transaction foun
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 wrote:
> > > On 14.02.2012 04:57, Dan Ports wrote:
> > >> The easiest answer would be to just treat every prepared
> > >> transaction found during recovery a
On Tue, Feb 14, 2012 at 09:27:58AM -0600, Kevin Grittner wrote:
> Heikki Linnakangas 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
On Tue, Feb 14, 2012 at 10:04:15AM +0200, Heikki Linnakangas wrote:
> Perhaps it would be simpler to add the extra information to the commit
> records of the transactions that commit after the first transaction is
> prepared. In the commit record, you would include a list of prepared
> transacti
"Kevin Grittner" wrote:
> This would tend to be more than a little inconvenient until the
> prepared statements pending at crash or shutdown were all
> committed or rolled back.
[sigh]
Probably obvious, but to avoid confusion:
s/prepared statements/prepared transactions/
-Kevin
--
Sent
Heikki Linnakangas wrote:
> On 14.02.2012 04:57, Dan Ports wrote:
>> Looking over the SSI 2PC code recently, I noticed that I
>> overlooked a case that could lead to non-serializable behavior
>> after a crash.
>>
>> When we PREPARE a serializable transaction, we store part of the
>> SERIALIZABLEXA
On 14.02.2012 04:57, Dan Ports wrote:
Looking over the SSI 2PC code recently, I noticed that I overlooked a
case that could lead to non-serializable behavior after a crash.
When we PREPARE a serializable transaction, we store part of the
SERIALIZABLEXACT in the statefile (in addition to the list
Looking over the SSI 2PC code recently, I noticed that I overlooked a
case that could lead to non-serializable behavior after a crash.
When we PREPARE a serializable transaction, we store part of the
SERIALIZABLEXACT in the statefile (in addition to the list of SIREAD
locks). One of the pieces of
