Re: [HACKERS] SSI rw-conflicts and 2PC

2012-02-29 Thread Heikki Linnakangas
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

Re: [HACKERS] SSI rw-conflicts and 2PC

2012-02-29 Thread Kevin Grittner
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

Re: [HACKERS] SSI rw-conflicts and 2PC

2012-02-22 Thread Jeff Davis
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

Re: [HACKERS] SSI rw-conflicts and 2PC

2012-02-14 Thread Heikki Linnakangas
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

Re: [HACKERS] SSI rw-conflicts and 2PC

2012-02-14 Thread Kevin Grittner
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

Re: [HACKERS] SSI rw-conflicts and 2PC

2012-02-14 Thread Kevin Grittner
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

Re: [HACKERS] SSI rw-conflicts and 2PC

2012-02-14 Thread Dan Ports
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

Re: [HACKERS] SSI rw-conflicts and 2PC

2012-02-14 Thread Dan Ports
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

[HACKERS] SSI rw-conflicts and 2PC

2012-02-13 Thread Dan Ports
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