Re: Testing with concurrent sessions

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