You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This was reported by Nikolay Samofatov in fb-devel.
Alex replaced CHECK_HANDLE_MEMBER macro with getHandle function call.
This is not semantically equivalent, as getHandle raises exceptions,
while CHECK_HANDLE_MEMBER didn't.
The exceptions are than handled here:
{
....
}
catch (const Firebird::Exception& ex) {
ISC_STATUS_ARRAY local_status;
memset(local_status, 0, sizeof(local_status));
/* It would be nice to log an error to the user, instead of just
terminating them! */
port->send_response(sendL, 0, 0, local_status, false);
port->disconnect(sendL, receive); /* Well, how about this... */
return false;
}
Which abruptly terminates the client connection.
In the field I assume this is the reason of GBAK failing with the
following errors on the output:
...
gbak:18920000 records written
gbak:18940000 records written
gbak:error accessing BLOB column PCH_OLDVALUE -- continuing
gbak: ERROR:Unable to complete network request to host "localhost".
gbak: ERROR: Error reading data from the connection.
gbak:error accessing BLOB column PCH_NEWVALUE -- continuing
gbak: ERROR:Unable to complete network request to host "localhost".
gbak: ERROR: Error reading data from the connection.
... [about 50 more errors reading connection]...
And the following corresponding errors in firebird.log:
BV1 Sun Dec 28 20:24:25 2008
invalid BLOB handle
BV1 (Client) Sun Dec 28 20:24:26 2008
INET/inet_error: send errno = 10053
BV1 (Client) Sun Dec 28 20:24:26 2008
INET/inet_error: send errno = 10053
... [about 50 more errors about aborted connection]...
This is not the root issue of GBAK problem we have here, and as such I
cannot treat this as critical issue right now, but this has to be fixed IMO.
Submitted by: @AlexPeshkoff
This was reported by Nikolay Samofatov in fb-devel.
Alex replaced CHECK_HANDLE_MEMBER macro with getHandle function call.
This is not semantically equivalent, as getHandle raises exceptions,
while CHECK_HANDLE_MEMBER didn't.
The exceptions are than handled here:
{
....
}
catch (const Firebird::Exception& ex) {
ISC_STATUS_ARRAY local_status;
memset(local_status, 0, sizeof(local_status));
Firebird::stuff_exception(local_status, ex);
gds__log_status(0, local_status);
/* It would be nice to log an error to the user, instead of just
terminating them! */
port->send_response(sendL, 0, 0, local_status, false);
port->disconnect(sendL, receive); /* Well, how about this... */
return false;
}
Which abruptly terminates the client connection.
In the field I assume this is the reason of GBAK failing with the
following errors on the output:
...
gbak:18920000 records written
gbak:18940000 records written
gbak:error accessing BLOB column PCH_OLDVALUE -- continuing
gbak: ERROR:Unable to complete network request to host "localhost".
gbak: ERROR: Error reading data from the connection.
gbak:error accessing BLOB column PCH_NEWVALUE -- continuing
gbak: ERROR:Unable to complete network request to host "localhost".
gbak: ERROR: Error reading data from the connection.
... [about 50 more errors reading connection]...
And the following corresponding errors in firebird.log:
BV1 Sun Dec 28 20:24:25 2008
invalid BLOB handle
BV1 (Client) Sun Dec 28 20:24:26 2008
INET/inet_error: send errno = 10053
BV1 (Client) Sun Dec 28 20:24:26 2008
INET/inet_error: send errno = 10053
... [about 50 more errors about aborted connection]...
This is not the root issue of GBAK problem we have here, and as such I
cannot treat this as critical issue right now, but this has to be fixed IMO.
Commits: 4b20155
The text was updated successfully, but these errors were encountered: