On Fri, 2002-08-30 at 13:22, John Gray wrote:
> I've been wondering about the following (this is pseudocode, with the
> main loop unrolled):
>
> LOG("A.out","step 1");
> LOG("B.out","step 1");
> LOG("C.out","step 1");
> PQsendQuery(A, ' whatever '); // Only executed if schedule lists one
> PQsendQuery(B, ' whatever 2 ');
> PQsendQuery(C, ' whatever 3 ');
> sleep(n); // To allow queries to run. [See below for alternative]
> PQconsumeInput(A);
> if ! PQisbusy(A) {
> LOG("A.out",PQgetResult(A)); // Actually a while(PQgetResult)
> ... etc. for B and C
> LOG("A.out","step 2");
> LOG("B.out","step 2");
> LOG("C.out","step 2");
> PQsendQuery(A, ' whatever next ');
> ... and so on.
Following the philosophy of "release early, release often" (a convenient
excuse to release poor code upon humanity) I present the following. This
is my first shot at using libPQ, so I'm sure it has various problems.
However, it does appear to work. It takes a schedule file (also
attached) and demonstrates tuple visibility and a deadlock. Obviously,
that's not very exciting, but it is an example of how such a thing might
work.
The current schedule uses two backends, but there is no limit in
principle to the number of backends involved.
I compiled with:
gcc -Wall -I/usr/local/pgsql/include -L/usr/local/pgsql/lib -lpq -o
vistest vistest.c
and then ran
./vistest sqltest example_schedule examp
(having first created a database called sqltest). Two output files,
examp_0 and examp_1 will be produced, representing the output from the
two backends. Note that comments and step markers are logged to both
files.
This is all a bit ragged and is only intended as a proof of concept
idea.
Regards
John
--
John Gray
Azuli IT
www.azuli.co.uk