Skip Menu |

This queue is for tickets about the DBD-Pg CPAN distribution.

Report information
The Basics
Id: 113676
Status: open
Priority: 0/
Queue: DBD-Pg
People
Owner: greg [...] turnstep.com
Requestors: pjuhasz [...] uhusystems.com
Cc:
AdminCc:
Bug Information
Severity: Important
Broken in: (no value)
Fixed in: (no value)

History Show all quoted text
  Mon Apr 11 05:28:07 2016 pjuhasz [...] uhusystems.com - Ticket created
Subject: Autocommit off makes async mode useless
Date: Mon, 11 Apr 2016 11:27:54 +0200
To: bug-DBD-Pg [...] rt.cpan.org
From: Peter Juhasz <pjuhasz [...] uhusystems.com>
Hello, we've run into a rather insidious problem while trying to use DBD::Pg's support for async queries. Setting the AutoCommit attribute false will cause the driver to treat queries as part of an ongoing transaction which must be explicitly committed or rolled back by the user. However, these transactions are started automatically and implicitly by the driver, and this is implemented in DBD::Pg by sending a BEGIN command before the query itself. And the problem is that this BEGIN is sent in a blocking way, with PQexec, whether the query is async or not. So in effect, when there is a network problem or the database response is delayed for any reason, the supposedly asynchronous application will hang on the first query of the transaction. System/version information: DBI 1.633 DBD::Pg 3.5.1 Linux xxx 4.4.6-200.fc22.x86_64 #1 SMP This is perl 5, version 20, subversion 3 (v5.20.3) built for x86_64 -linux-thread-multi best regards, Peter Juhasz
  Sun Apr 02 22:25:37 2017 greg [...] turnstep.com - Taken
  Sun Apr 02 22:28:28 2017 greg [...] turnstep.com - Status changed from 'new' to 'open'
  Sun Apr 02 22:28:28 2017 greg [...] turnstep.com - Severity Important added
  Sun Feb 04 15:16:26 2018 greg [...] turnstep.com - Correspondence added
Show quoted text
> And the problem is that this BEGIN is sent in a blocking way, with PQexec
Quite the tricky problem - I am not sure how we can fix this. We cannot send the BEGIN async and return control to the user, as they are expecting the "real" query to be async and not know that they still haven't sent the first one. How would the real query be sent? Wait until the caller agrees to wait for /check the query, then wait for the begin, send the real query, and do the wait again? That's quite a bit of magic-at-a-distance happening there. Open to any solutions anyone has, but it may end up being a disallowed combo, or a strong documentation warning?