apr-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 47431] New: query return code mishandled when using postgresql transactions with ignore errors set
Date Thu, 25 Jun 2009 20:45:02 GMT

           Summary: query return code mishandled when using postgresql
                    transactions with ignore errors set
           Product: APR
           Version: 1.3.4
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P3
         Component: APR-util
        AssignedTo: bugs@apr.apache.org
        ReportedBy: wayne_jensen@trendmicro.com

Created an attachment (id=23883)
 --> (https://issues.apache.org/bugzilla/attachment.cgi?id=23883)
Patch vs 1.3.4 version of apr_dbd_pgsql.c

This pertains to apr_dbd_pgsql.so in the dbd utilities, functions
dbd_pgsql_query and dbd_pgsql_pquery_internal.

The same variable, 'ret', is re-used for 3 different purposes:  1) to store
native Postgresql return codes for the primary query; 2) to store native
Postgresql return codes for supporting queries related to transaction
SAVEPOINTs; 3) to store and return the appropriate APR return code to the
caller. This leads to two issues in the current trunk.

Because ret is used first for native postgresql codes and then for returning an
APR error code, the native code must be translated.  The dbd functions only
specify 0 on success, and some error code on failure, and thus do not require
meaningful translation of any native error code.  However, postgres does not
use 0 for a success code in libpq calls, so it IS required to modify ret to 0
for any postgres success codes.  This is done correctly when transactions are
not used, or when transactions with default mode are used.  But when
APR_DBD_TRANSACTION_IGNORE_ERRORS mode is used, the functions in question will
set a postgres SAVEPOINT prior to executing the primary query, and release or
rollback to the savepoint depending on query success or failure.  In the case
of a successful primary query, the variable ret is set to the return code of
the query that releases the savepoint, but that code is not translated back to
0 on success.

The second problem is that on failure of the primary query, the return code
from that primary query is lost entirely due to the re-use of 'ret' for the
rollback to the savepoint.

Attached is a patch that should remedy this situation.  I added a second
variable, 'transret' specifically to take the return codes related to operation
around transaction SAVEPOINTs.  The original 'ret' value from the primary query
is no longer modified after initial translation.

Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

To unsubscribe, e-mail: bugs-unsubscribe@apr.apache.org
For additional commands, e-mail: bugs-help@apr.apache.org

View raw message