Re: [Firebird-devel] File and table sizes in Firebird 4.0
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 Rotteveel Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Blobs and OCTET_LENGTH
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, it's blob itself: In memory: ULONG blb_length; // Total length of data sans segments In ODS: ULONG blh_length; // Total length of data Ok, but that doesn't solve the problem that it is possible to create larger blobs, with no way to know whether the value reported by OCTET_LENGTH is correct or has been truncated. Would it make sense to fix the value at 0x when blobs are 4GB - 1 or larger? Then although OCTET_LENGTH still reports the wrong value, at least it is a consistent signal value. Mark -- Mark Rotteveel Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Blobs and OCTET_LENGTH
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_length; // Total length of data sans segments In ODS: ULONG blh_length; // Total length of data Dmitry Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] Blobs and OCTET_LENGTH
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 a signal value (e.g. -1)? Mark -- Mark Rotteveel Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] File and table sizes in Firebird 4.0
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 mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] File and table sizes in Firebird 4.0
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. In other words, what you initially said, "It is still limited to uint32 for total size", is not correct. Ok, I'll trial and error the maximum size... Mark -- Mark Rotteveel Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
