Testing with concurrent sessions
in [PgSql]
|
From: Markus Wanner on 15 Jan 2010 00:53 Hi, Kevin Grittner wrote: > C'mon, you could have tried to inspire a *bit* more confidence by > calling it version 0.1 or something! ;-) LOL As David used to say: JFDI > I found that I just needed to ask for python-twisted. Oh, sorry, yes, requirements: python, twisted. I must admit that I haven't ever tested on python 2.6 before. I'll try that (especially as it's the staircase to 3.0, IIUC). Two more things: the concurrent update test (in the patch part) is complete, while the second one is just a skeleton, ATM. (Just does a concurrent COMMIT without actually doing anything). Second: at the very end of pg_dtester.py, you find the line: reporter = StreamReporter() Try a CursesReporter() instead, it gives much nicer output! Regards Markus Wanner -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: "Kevin Grittner" on 15 Jan 2010 10:07 Markus Wanner <markus(a)bluegap.ch> wrote: > I must admit that I haven't ever tested on python 2.6 before. I'll > try that (especially as it's the staircase to 3.0, IIUC). I don't use python much, so I can't comment on that. I do see that my system has these two versions on it, with a symlink that makes 2.6 the default. Python 2.6.2 (release26-maint, Apr 19 2009, 01:56:41) [GCC 4.3.3] on linux2 Python 3.0.1+ (r301:69556, Apr 15 2009, 15:59:22) [GCC 4.3.3] on linux2 I haven't quite gotten it to work yet; I'll start over with 3.0 and see how it goes. I'll also attach the results of the 2.6 attempt. > Try a CursesReporter() instead, it gives much nicer output! Thanks, I'll try it. A few other issues in testing so far: (1) I see that a 'make dcheck' does a 'make install'. That's not right. For one thing I usually install in a location where I need to sudo to install; but more importantly, I want to do all checks *before* I install. It's easy enough to work around that for now, but I don't think it's acceptable long-term. (2) After a 'make dcheck' failure, the cluster created for the testing is left running. (3) If the install could check dependencies, report problems, and refuse to install without required packages, that would be less confusing for python novices (like me). Perhaps some of these problems will go away with python 3.0, but I figured I should pass the info along. Thanks again for this. It should help me a lot. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: "Kevin Grittner" on 15 Jan 2010 10:09 I wrote: > I'll also attach the results of the 2.6 attempt. Let's try that again. -Kevin
From: "Markus Wanner" on 15 Jan 2010 10:22 Hi, Quoting "Kevin Grittner" <Kevin.Grittner(a)wicourts.gov>: > I haven't quite gotten it to work yet; I'll start over with 3.0 and > see how it goes. Let's stick to 2.x versions, first... > I'll also attach the results of the 2.6 attempt. Thanks, that looks already pretty promising. ;-) > A few other issues in testing so far: > > (1) I see that a 'make dcheck' does a 'make install'. That's not > right. For one thing I usually install in a location where I need > to sudo to install; but more importantly, I want to do all checks > *before* I install. It's easy enough to work around that for now, > but I don't think it's acceptable long-term. It does: "temp_install: creating temporary installation" means it's running make install in the background. > (2) After a 'make dcheck' failure, the cluster created for the > testing is left running. That counts as a bug. I also get that from time to time (and with Postgres-R testing on 3+ instances, it's even more annoying). Note that the error just before that is, that a psql process it starts cannot connect to its postmaster ("startup of test test-conn-0A failed, skipping.") Please check the log (src/test/regress/dtester.log) for why that failed in the first place. Can you connect manually to the database (that's still running after a make dcheck)? > (3) If the install could check dependencies, report problems, and > refuse to install without required packages, that would be less > confusing for python novices (like me). I'm not exactly a distutils hacker... Anybody else got any clue here? > Perhaps some of these problems will go away with python 3.0, but I > figured I should pass the info along. I'd rather suspect that more of them will arise. Regards Markus -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: "Kevin Grittner" on 15 Jan 2010 10:34
"Markus Wanner" <markus(a)bluegap.ch> wrote: > Quoting "Kevin Grittner" <Kevin.Grittner(a)wicourts.gov>: >> I haven't quite gotten it to work yet; I'll start over with 3.0 >> and see how it goes. > > Let's stick to 2.x versions, first... OK > It does: "temp_install: creating temporary installation" means > it's running make install in the background. OK, sorry for misreading that. >> (2) After a 'make dcheck' failure, the cluster created for the >> testing is left running. > > That counts as a bug. I also get that from time to time (and with > Postgres-R testing on 3+ instances, it's even more annoying). > > Note that the error just before that is, that a psql process it > starts cannot connect to its postmaster ("startup of test > test-conn-0A failed, skipping.") Please check the log > (src/test/regress/dtester.log) for why that failed in the first > place. Not sure what's relevant there. Entire file tarball attached. > Can you connect manually to the database (that's still running > after a make dcheck)? Yes I can. Any queries you'd like me to run in there? -Kevin |