Testing with concurrent sessions
in [PgSql]
|
From: Martijn van Oosterhout on 11 Jan 2010 03:46 On Mon, Jan 11, 2010 at 04:17:42AM -0000, Greg Sabino Mullane wrote: > > Because you'd have to build DBD::Pg against the new libpq, as you do > > psql. That means you need DBD::Pg sources and the build environment for > > Perl (headers etc) not just a working Perl runtime. Big difference. > > Yes, but that is what I was envisioning. As you point out, that's the > only sane way to make sure we have a good version of DBD::Pg with > which to test. As a side effect, it put libpq through some extra > paces as well. :) Is there a reason why you're suggesting using DBI? There is also the Pg perl module which works as well and is one tenth of the size. It also doesn't have external dependancies. It's just a plain wrapper around libpq, which for the purposes of testing may be better. http://search.cpan.org/~mergl/pgsql_perl5-1.9.0/Pg.pm Have a nice day, -- Martijn van Oosterhout <kleptog(a)svana.org> http://svana.org/kleptog/ > Please line up in a tree and maintain the heap invariant while > boarding. Thank you for flying nlogn airlines.
From: "Greg Sabino Mullane" on 11 Jan 2010 12:42 -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 > Is there a reason why you're suggesting using DBI? There is also the Pg > perl module which works as well and is one tenth of the size. It also > doesn't have external dependancies. It's just a plain wrapper around > libpq, which for the purposes of testing may be better. > > http://search.cpan.org/~mergl/pgsql_perl5-1.9.0/Pg.pm Works as well? Did you take a look at that link? The last update was early 2000, which should give you an indication of just how dead it is. - -- Greg Sabino Mullane greg(a)turnstep.com PGP Key: 0x14964AC8 201001111241 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAktLYtwACgkQvJuQZxSWSsjNJgCg1IZBNIZsUMZ2V83/NjgJnrGO 3NEAoK/w0byO45zmni/i9lnhliD4UpkU =ndmb -----END PGP SIGNATURE----- -- 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: Martijn van Oosterhout on 11 Jan 2010 16:30 On Mon, Jan 11, 2010 at 05:42:08PM -0000, Greg Sabino Mullane wrote: > > Is there a reason why you're suggesting using DBI? There is also the Pg > > perl module which works as well and is one tenth of the size. It also > > doesn't have external dependancies. It's just a plain wrapper around > > libpq, which for the purposes of testing may be better. > > > > http://search.cpan.org/~mergl/pgsql_perl5-1.9.0/Pg.pm > > Works as well? Did you take a look at that link? The last update was > early 2000, which should give you an indication of just how dead > it is. Dead or not, it still works, even against 8.4. I have many programs that use it. It's simply a wrapper around the libpq interface and as long as the libpq interface remains stable (which we go to great pains to do), so will this module. Given the talk of importing some perl module into the postgresql tree it just seemed more logical to me to take something that was close to libpq and had no external dependancies than taking a module with an external dependancy (namely DBI). Have a nice day, -- Martijn van Oosterhout <kleptog(a)svana.org> http://svana.org/kleptog/ > Please line up in a tree and maintain the heap invariant while > boarding. Thank you for flying nlogn airlines.
From: Markus Wanner on 14 Jan 2010 15:08 Hi, Markus Wanner wrote: > Sorry, if that didn't get clear. I'm trying to put together something I > can release real soon now (tm). I'll keep you informed. Okay, here we go: dtester version 0.0. This emerged out of Postgres-R, where I don't just need to test multiple client connections, but multiple postmasters interacting with each other. None the less, it may be suitable for other needs as well, especially testing with concurrent sessions. I've decided to release this as a separate project named dtester, as proposed by Michael Tan (thanks for your inspiration). It's certainly missing lots of things, mainly documentation. However, I've attached a patch which integrates nicely into the Postgres Makefiles, so you just need to say: make dcheck. That very same patch includes a test case with three concurrent transactions with circular dependencies, where the current SERIALIZABLE isolation level fails to provide serializability. Installing dtester itself is as simple as 'python setup.py install' in the extracted archive's directory. Go try it, read the code and simply ask, if you get stuck. I'll try to come up with some more documentation and such... Regards Markus Wanner
From: "Kevin Grittner" on 14 Jan 2010 15:23
Markus Wanner <markus(a)bluegap.ch> wrote: > Okay, here we go: dtester version 0.0. C'mon, you could have tried to inspire a *bit* more confidence by calling it version 0.1 or something! ;-) > It's certainly missing lots of things, mainly documentation. > However, I've attached a patch which integrates nicely into the > Postgres Makefiles, so you just need to say: make dcheck. That sounds very cool. > That very same patch includes a test case with three concurrent > transactions with circular dependencies, where the current > SERIALIZABLE isolation level fails to provide serializability. Fantastic! I'll expand that a bit.... > Installing dtester itself is as simple as 'python setup.py > install' in the extracted archive's directory. > > Go try it, read the code and simply ask, if you get stuck. I'll > try to come up with some more documentation and such... I'm reading through it all now. Expect feedback soon! And THANK YOU VERY MUCH! -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 |