Re: [HACKERS] Review: Row-level Locks & SERIALIZABLE transactions, postgres vs. Oracle

2010-09-24 Thread Kevin Grittner
Kevin Grittner wrote: > This now compiles and passes regression tests. I still need to > re-run all the other tests which Florian and I previously used to > test the patch. I don't have any reason to expect that they will > now fail, but one need to be thorough. Once that is confirmed, I > th

Re: [HACKERS] Review: Row-level Locks & SERIALIZABLE transactions, postgres vs. Oracle

2010-08-06 Thread Florian Pflug
On Aug3, 2010, at 00:43 , Florian Pflug wrote: > Sounds good. That'll also give me some time to test the RI trigger > infrastructure now that I've removed the crosscheck code. Ok, I've found some time do run some additional tests. I've created a small test suite to compare the behaviour of native

Re: [HACKERS] Review: Row-level Locks & SERIALIZABLE transactions, postgres vs. Oracle

2010-08-02 Thread Florian Pflug
Hi I've updated mvcc.sgml to explain the new serialization conflict rules for row-level locks, and added a paragraph to backend/executor/README that explains the implementation of those. I've chosen backend/executor/README because it already contains a description of UPDATE handling in READ COM

Re: [HACKERS] Review: Row-level Locks & SERIALIZABLE transactions, postgres vs. Oracle

2010-07-18 Thread Kevin Grittner
Joe Conway wrote: > "make dcheck" is running now (although seems rather slow). Yeah, most of those tests completely reset the environment for each permutation. I thought about changing it to update back to the same "visible" initial state each time, but it struck me that since this would accu

Re: [HACKERS] Review: Row-level Locks & SERIALIZABLE transactions, postgres vs. Oracle

2010-07-18 Thread Joe Conway
On 07/18/2010 07:02 PM, Joe Conway wrote: > On 07/18/2010 11:41 AM, Kevin Grittner wrote: >> To run the tests included in the main patch (if you have python, >> twisted, etc., installed), after the make check, run make dcheck. > > Question about dcheck. After install of twisted, I get: > > 8<

Re: [HACKERS] Review: Row-level Locks & SERIALIZABLE transactions, postgres vs. Oracle

2010-07-18 Thread Joe Conway
On 07/18/2010 11:41 AM, Kevin Grittner wrote: > To run the tests included in the main patch (if you have python, > twisted, etc., installed), after the make check, run make dcheck. Question about dcheck. After install of twisted, I get: 8<- bash-4.1$ make dcheck make -

Re: [HACKERS] Review: Row-level Locks & SERIALIZABLE transactions, postgres vs. Oracle

2010-07-18 Thread Joe Conway
On 07/18/2010 11:41 AM, Kevin Grittner wrote: > > I'm attaching a fresh patch, but I think the only differences are: Thanks for the detailed info. I managed to make my way through much of the background info in the papers and wiki yesterday, so I will start reviewing shortly. > If you spot an

Re: [HACKERS] Review: Row-level Locks & SERIALIZABLE transactions, postgres vs. Oracle

2010-07-18 Thread Andrew Dunstan
Kevin Grittner wrote: Comment style seems to be defined here: http://developer.postgresql.org/pgdocs/postgres/source-format.html as being: /* * comment text begins here * and continues here */ You have these formats in your patch: /* comment text begins here * and continues here

Re: [HACKERS] Review: Row-level Locks & SERIALIZABLE transactions, postgres vs. Oracle

2010-07-18 Thread Kevin Grittner
Florian Pflug wrote: > On Jul17, 2010, at 18:25 , Kevin Grittner wrote: >> * Does it follow the project coding guidelines? >> >> Comments are not all in standard style. > Does that refer to the language used, or to the formatting? Formatting. Comment style seems to be defined here: http://

Re: [HACKERS] Review: Row-level Locks & SERIALIZABLE transactions, postgres vs. Oracle

2010-07-17 Thread Florian Pflug
On Jul17, 2010, at 18:25 , Kevin Grittner wrote: > * Does it include reasonable tests, necessary doc patches, etc? > > Documentation changes are needed in the "Concurrency Control" > chapter. > > <...> > > * Do we want that? > > Yes. We seem to have reached consensus on the -hackers list to t

Re: [HACKERS] Review: Row-level Locks & SERIALIZABLE transactions, postgres vs. Oracle

2010-07-17 Thread Joseph Conway
On 7/17/10 12:09 PM, Kevin Grittner wrote: > Joe Conway wrote: > >> Should I be installing Florian's patch in addition to yours when I >> start testing? > > There's some manual fix-up needed, primarily because we need to > differentiate between SERIALIZABLE and REPEATABLE READ isolation > leve

Re: [HACKERS] Review: Row-level Locks & SERIALIZABLE transactions, postgres vs. Oracle

2010-07-17 Thread Kevin Grittner
Joe Conway wrote: > Should I be installing Florian's patch in addition to yours when I > start testing? There's some manual fix-up needed, primarily because we need to differentiate between SERIALIZABLE and REPEATABLE READ isolation levels, and therefore replaced the IsXactIsoLevelSerializable

Re: [HACKERS] Review: Row-level Locks & SERIALIZABLE transactions, postgres vs. Oracle

2010-07-17 Thread Joe Conway
On 07/17/2010 09:25 AM, Kevin Grittner wrote: > I was concerned about its interaction with the other serializable > patch (by myself and Dan Ports), so I also combined the patches and > tested. Florian's pgbench test did expose bugs in the *other* > patch, which I then fixed in the combined settin

Re: [HACKERS] Review: Row-level Locks & SERIALIZABLE transactions, postgres vs. Oracle

2010-07-17 Thread Kevin Grittner
= Submission review = * Is the patch in context diff format? Yes. * Does it apply cleanly to the current CVS HEAD? Yes. * Does it include reasonable tests, necessary doc patches, etc? There is one pgbench test which shows incorrect behavior without the p