Lists: | pgsql-hackers |
---|
From: | "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> |
---|---|
To: | <andrew(at)dunslane(dot)net>,<robertmhaas(at)gmail(dot)com> |
Cc: | <peter_e(at)gmx(dot)net>,<david(at)kineticode(dot)com>, <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Testing with concurrent sessions |
Date: | 2010-01-07 02:31:20 |
Message-ID: | 4B44F318020000250002DE3D@gw.wicourts.gov |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
Andrew Dunstan wrote:
> Robert Haas wrote:
>> Doing this without DBI is going to be ten times harder than doing
>> it with DBI. Are we really sure that's not a viable option?
> In the buildfarm? Yes, I think so. The philosophy of the buildfarm
> is that it should do what you would do yourself by hand.
>
> And adding DBI as a requirement for running a buildfarm member
> would be a significant extra barrier to entry, ISTM. (I am very
> fond of DBI, and use it frequently, BTW)
>
> I'm persuadable on most things, but this one would take a bit of
> doing.
As far as I've been able to determine so far, to call psql in a
relatively portable way would require something like this:
http://perldoc.perl.org/perlfork.html
Is that really better than DBI?
Don't we need some way to routinely test multi-session issues?
Other ideas?
-Kevin
From: | "David E(dot) Wheeler" <david(at)kineticode(dot)com> |
---|---|
To: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov> |
Cc: | <andrew(at)dunslane(dot)net>, <robertmhaas(at)gmail(dot)com>, <peter_e(at)gmx(dot)net>, <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Testing with concurrent sessions |
Date: | 2010-01-07 17:08:15 |
Message-ID: | BC4AC758-3285-45D0-B070-D14058E07B4E@kineticode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
On Jan 6, 2010, at 6:31 PM, Kevin Grittner wrote:
> As far as I've been able to determine so far, to call psql in a
> relatively portable way would require something like this:
>
> http://perldoc.perl.org/perlfork.html
Here's an example using IPC::Open3:
#!/usr/local/bin/perl -w
use strict;
use warnings;
use IPC::Open3;
use Symbol 'gensym';
use constant EOC => "__DONE__\n";
my ($in1, $out1, $err1) = (gensym, gensym, gensym);
my ($in2, $out2, $err2) = (gensym, gensym, gensym);
my $pid1 = open3 $in1, $out1, $err1, 'bash';
my $pid2 = open3 $in2, $out2, $err2, 'bash';
print $in1 "cd ~/dev/postgresql\n";
print $in1 "ls doc\n";
print $in1 "echo ", EOC;
while ((my $line = <$out1>)) {
last if $line eq EOC;
print "LS: $line";
}
print "#### Finished file listing\n\n";
print $in2 "cd ~/dev/postgresql\n";
print $in2 "head -4 README\n";
print $in2 "echo ", EOC;
while (defined( my $line = <$out2> )) {
last if $line eq EOC;
print "HEAD: $line";
}
print "#### Finished reading README\n\n";
print $in1 "exit\n";
print $in2 "exit\n";
waitpid $pid2, 0;
print "#### All done!\n";
With that, I get:
LS: KNOWN_BUGS
LS: MISSING_FEATURES
LS: Makefile
LS: README.mb.big5
LS: README.mb.jp
LS: TODO
LS: bug.template
LS: src
#### Finished file listing
HEAD: PostgreSQL Database Management System
HEAD: =====================================
HEAD:
HEAD: This directory contains the source code distribution of the PostgreSQL
#### Finished reading README
#### All done!
I could easily write a very simple module to abstract all that stuff for you, then you could just do something like:
my $psql1 = Shell::Pipe->new(qw(psql -U postgres));
my $psql2 = Shell::Pipe->new(qw(psql -U postgres));
$psql1->print('SELECT * from pg_class');
while (my $line = $psql1->readln) { print "Output: $line\n" }
$psql1->close;
All I'd need is some more reliable way than "echo "DONE__\n" to be able to tell when a particular command has finished outputting.
Thoughts?
Best,
David