On 06-08-2021 14:37, Jiří Činčura wrote:
Definitely BLOB size should be bigger. Index key length too.
The listed blob size is even wrong for Firebird 2.5. I created a 128 GB
blob on Firebird 2.5 with page size 16KB. I wonder if it intended to say
>32GB instead of <32GB.
Mark
--
Mark Rotteve
On 07-08-2021 11:38, Dmitry Yemanov wrote:
07.08.2021 12:31, Mark Rotteveel wrote:
Currently, for blobs that are 4GB or longer, OCTET_LENGTH will
silently truncate the length. This means that a 4GB blob is reported
as length 0, a 5GB blob as 1,073,741,824.
It's not OCTET_LENGTH who's guilty,
07.08.2021 12:31, Mark Rotteveel wrote:
Currently, for blobs that are 4GB or longer, OCTET_LENGTH will silently
truncate the length. This means that a 4GB blob is reported as length 0,
a 5GB blob as 1,073,741,824.
It's not OCTET_LENGTH who's guilty, it's blob itself:
In memory:
ULONG blb_len
Currently, for blobs that are 4GB or longer, OCTET_LENGTH will silently
truncate the length. This means that a 4GB blob is reported as length 0,
a 5GB blob as 1,073,741,824.
Is this something that can be fixed? Or alternatively, would it be
possible to raise an error, warning, or maybe return
07.08.2021 10:43, Mark Rotteveel wrote:
In other words, what you initially said, "It is still limited to uint32 for total size",
is not correct.
It was about "total size" internal structure member. I don't know if it is used for
anything else but info item.
--
WBR, SD.
Firebird-Devel m
On 06-08-2021 18:20, Dimitry Sibiryakov wrote:
06.08.2021 18:11, Mark Rotteveel wrote:
That document says <32GB for blob, if it is restricted to unit32, then
the limit should be <4GB, right?
Limit is 4GB for corresponding info item. The BLOB itself can be
longer if you "just read/write" it
