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 Linnakangasheikki.linnakan...@enterprisedb.com wrote:
On 14.02.2012 04:57, Dan Ports wrote:
The easiest answer would be to just
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
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
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
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
Kevin Grittner kevin.gritt...@wicourts.gov 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
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
transactions
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
