isc_segstr_eof not set in first call to isc_get_segment()

                 Key: CORE-6184
             Project: Firebird Core
          Issue Type: Bug
          Components: API / Client Library
    Affects Versions: 3.0.4
            Reporter: Cris Doorn

When you read a blob and all data is returned in the first call to 
isc_get_segment(), both the returned status and the status_vector[1] remain 0.

Since most people will keep reading the blob-data while the status equals 0 or 
the vector equals isc_segment, like this:

while (blob_stat == 0 || status_vector[1] == isc_segment) { 

a second call to isc_get_segment() is made. This second time it does indeed 
return isc_segstr_eof in status_vector[1].

Although this might seem totally harmless, it really isn't because it affects 
the performance very badly.
The second call to isc_get_segment(), returning no data at all, thus only 
returning isc_segstr_eof, is far more slower than the first call to 

By using the actual blob size retrieved with isc_blob_info(), the read loop can 
be modified so that it stops reading when all data is retrieved. 
This prevents the extra, very slow, call to isc_get_segment()

To give an impression of the impact, we'll fetch 1000 rows with each 2 small 
blobs subtype 1. 

The original code with 2 calls to isc_get_segment() for each blob, took 7575 ms
After removing the second call to isc_get_segment(), it only took 448 ms.

Without the extra call, the code runs about 17 times faster!

Returning the isc_segstr_eof directly in the first call when all data is 
returned seems like the fastest solution to me.
This also prevents a second round trip over the network.
Fixing the reason why the second call is so much slower might also be great. 

Kind regards,

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:


Firebird-Devel mailing list, web interface at

Reply via email to