Thank you for all the clarifications. I read the discussion in https://github.com/h2database/h2database/issues/1808. The minimal testcase for 1808 reproduction does parallel updates and reads on a LOB-containing row. Am I safe from issue 1808 If I don't do anything like that, i.e. if I have a single connection to an embedded DB and do everything sequentially in that connection?
On Wednesday, September 2, 2020 at 12:09:04 PM UTC+2 Evgenij Ryazanov wrote: > 1) Is an in-place LOB different from VARBINARY? Does it - like a >> non-in-place LOB - require additional read operation? >> > In-place BLOBs are similar to BINARY VARYING and in-place CLOBs are > similar to CHARACTER VARYING in terms of their storage, but they use API of > LOBs. You can set MAX_LENGTH_INPLACE_LOB to a large enough value, change > your data types to BLOB (CLOB) and use the LOB API for them for now. Too > large values of MAX_LENGTH_INPLACE_LOB setting may be rejected or silently > ignored in the future, but most likely only when the issue 1808 will be > fixed, because we need a some workaround for it. > > >> 2) The LOB issue you mention looks like a stopper to me. Since large >> BINARY / VARBINARY works fine and do not cause OOM problems (at least in >> specific scenarios) would it be possible to add a new URL option that >> allows customization of the size limit for VARBINARY columns? > > We decided to make this limit not configurable. This limit is already very > large, usually DBMS have smaller limits for binary and character strings, > such as 64K or even 4K. > -- You received this message because you are subscribed to the Google Groups "H2 Database" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/h2-database/508b0300-154e-48f1-a647-6a875493995an%40googlegroups.com.
