Hi!
I'm not sure if this really a bug, unavoidable or even wanted: If I execute a query with PG_ASYNC and another sth is DESTROYed before I can fetch the results, the results are gone and the async sth is invalid (not executing). I assume this is because dbd_st_destroy calls handle_old_async, which lets any async query finish and discards the results.
Proof of concept:
use v5.36.0;
use DBI;
use DBD::Pg ':async';
my $dbh = DBI->connect('dbi:Pg:dbname=somedb;host=127.0.0.1;port=15432', 'testkasperl', '');
my %sths = (
async1 => $dbh->prepare(q{SELECT 'one'}, { pg_async => PG_ASYNC + PG_OLDQUERY_WAIT }),
async2 => $dbh->prepare(q{SELECT 'two'}, { pg_async => PG_ASYNC + PG_OLDQUERY_WAIT }),
);
$sths{async1}->execute;
$dbh->pg_result;
my ($async1_result) = $sths{async1}->fetchrow_array;
die 'wrong async1 result' unless $async1_result eq 'one';
$sths{async1}->finish;
say '-> now async2 is active...';
$sths{async2}->execute;
say '-> and async1 is DESTROYed which slurps up any pending async query -> async2 is now gone.';
delete $sths{async1};
say '-> and this fails.';
$dbh->pg_result;
say '-> and there is "no statement executing"';
my ($async2_result) = $sths{async2}->fetchrow_array;
die 'wrong async2 result' unless $async2_result eq 'two';
For me, this is a little surprising. I also don't see how I can guarantee that no old sth hanging around will fall out of scope or something between execute()ing a async query and awaiting the results.
Thanks!
Hi!
I'm not sure if this really a bug, unavoidable or even wanted: If I execute a query with
PG_ASYNCand another sth is DESTROYed before I can fetch the results, the results are gone and the async sth is invalid (not executing). I assume this is becausedbd_st_destroycallshandle_old_async, which lets any async query finish and discards the results.Proof of concept:
For me, this is a little surprising. I also don't see how I can guarantee that no old sth hanging around will fall out of scope or something between execute()ing a async query and awaiting the results.
Thanks!