[h2] H2 Database Engine: New version 2.3.232 released

[Andrei Tokar]

Hello,

A new version 2.3.232 of H2 is available at http://www.h2database.com
(you may have to click 'Refresh') and
https://github.com/h2database/h2database/releases/tag/version-2.3.232


For details, see the 'Change Log' at
http://www.h2database.com/html/changelog.html

New artefacts will be uploaded to maven repository shortly.

Have fun,
Andrei Tokar

-- 
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 h2-database+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/h2-database/bef09afd72d57d6d190c7e0e68aaa5d3eb4bb1e6.camel%40gmail.com.

[h2] Re: Issue with Java Heap Space and H2 Database

[Andrei Tokar]

Hi Mahima,
You did not even mention, if you are usin in-memory or persistent database, 
your connection URL should be the first thing to post. Database version 
would be helpful too.
If you suspect memory leak - H2 is just another java library, so follow 
standard best practices to detect JVM memory leaks (profiler, etc). If you 
increase java heap size and it did not change a thing - that sounds 
suspicious, at least time to reach unresponsive state should increase. When 
you say "optimize for large datasets", what does it mean exactly? 1.5 - 2 
million rows does not sound like a lot, unless your table is very wide or 
there are blobs involved. What else, besides H2 exists in the same process?
I doubt, that without answers to those questions anyone would be able to 
give you any kind of a meaningful advice.

On Friday, July 19, 2024 at 6:02:03 AM UTC-4 Mahima Chaubey wrote:

> Hello , 
>
> We are encountering frequent Java heap space issues approximately every 1 
> 1/2 hours after restarting the service. By the end of the day, our H2 
> database accumulates between 50 to 60 lakh (5 to 6 million) rows. However, 
> the database starts becoming unresponsive when it reaches only 15 to 20 
> lakh (1.5 to 2 million) rows.
>
> *Service Functionality Overview:* Our service fetches data from a 
> third-party API and stores it in the H2 database throughout the day. This 
> process is repeated frequently. Ideally, our setup should handle this 
> workload seamlessly. However, after fetching data around 4 to 5 times 
> (approximately 15 lakh records), we start encountering Java heap space 
> errors. Even simple operations like querying the count(*) become impossible.
>
> We have tried increasing the server's CPU cores and memory allocation, but 
> the issue persists.
>
> *Request for Assistance:* We suspect there might be a memory leak issue 
> with H2 database causing these problems. Could you please advise on:
>
>- Steps to diagnose and mitigate potential memory leaks in H2 database?
>- Best practices or configurations to optimise H2 database performance 
>with large datasets?
>
> Any guidance or support you could provide would be greatly appreciated. 
> Thank you for your attention to this matter.
>
> Best regards,
> Mahima
>
> ..

-- 
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 h2-database+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/h2-database/af68b2e6-ce2a-40f1-bcfd-5bc812f25fc0n%40googlegroups.com.

[h2] H2 Database Engine: New version 2.3.230 released

[Andrei Tokar]

Hello,

A new version 2.3.230 of H2 is available at http://www.h2database.com
(you may have to click 'Refresh') and
https://github.com/h2database/h2database/releases/tag/version-2.3.230


For details, see the 'Change Log' at
http://www.h2database.com/html/changelog.html

New artefacts will be uploaded to maven repository shortly.


Have fun,
Andrei Tokar

-- 
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 h2-database+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/h2-database/e00bd4cf445605d32881ba120118a0c505f65360.camel%40gmail.com.

[h2] Re: Changes to MVStore.getMetaMap() does not trigger commit()

[Andrei Tokar]

Hello Chris,
Just wondering what is your reason to call MVStore.getMetaMap()?
But if you do, please read it's javadoc:
This data is for informational purposes only.
The data is subject to change in future versions.
The data in this map should not be modified (changing system data may 
corrupt the store).

On Monday, June 10, 2024 at 5:57:57 AM UTC-4 Chris van Hinsbergen wrote:

> I found an issue, not sure it is a design choice or a bug. When I open a 
> new MVStore, and I only add entries in the meta map using 
> MVStore.getMetaMap().put("some","thing"), and I call store.commit(), it 
> returns -1. Closing the store and reopening it leaves me with a database 
> that does not have any metadata.
>
> However, when I also add an entry to some map, the data in the metamap IS 
> stored. So adding data to the meta map does not trigger the store to have 
> unsaved changes, but the metadata IS stored.
>
> Is this intended behavior?
>
> Thanks!
>
> Chris
>

-- 
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 h2-database+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/h2-database/bd0d57ad-d931-44eb-8fa4-5e6f7e78316an%40googlegroups.com.

[h2] Re: what data is removed during DEFRAG

[Andrei Tokar]

Plaese see nice recent message here 
. 
I hope it will help to manage your expectations about database file size.
On Monday, June 3, 2024 at 5:32:12 AM UTC-4 Rinse Lemstra wrote:

> My databases (mvstore) are growing rapidly, much more than I would expect 
> based on the entered data. I also see CPU usage increasing.
>
> Performing a DEFRAG reduces the database size significantly, sometimes by 
> 60-70%. Running SCRIPT TO / RUNSCRIPT also has a similar effect.
>
> How can I identify what 'pollution' is consuming so much space? Browsing 
> through the INFORMATION_SCHEMA has not provided any clues.
>
> We recently started using "CREATE MEMORY LOCAL TEMPORARY TABLE IF NOT 
> EXISTS" more frequently. Could this be related to the problem?
>

-- 
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 h2-database+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/h2-database/dbd67b4e-e095-4548-bed3-55122e4feb9en%40googlegroups.com.

Re: [h2] Re: Duplicate records when order by date?

[Andrei Tokar]

Hi Peter,
IMHO, Evgenij is 100% correct. This is NOT a bug.

If something (like offset pagination) is not uncommon, it does not make it 
the best practice.
If PostgressSQL always yields some deterministic behaviour, where 
non-determinism is allowed by SQL standard (and common sence),
 it does not mean that any other RDBMS should behave similarly.

I would follow Evgenij's advice and organize pagination on some unique 
attribute(s), and without OFFSET, but with adjustable WHERE condition, 
instead.
It would also cover cases of concurrent inserts / deletes (messing up all 
offsets), during your pages traversal.


On Saturday, April 13, 2024 at 11:34:54 AM UTC-4 Peter Borissow wrote:

> Thanks Evgeni, as always, for your prompt response! 
>
> So you don't think this is a bug? Pagination using offset and limit is not 
> uncommon. 
>
> Also, I should have mentioned this earlier but I don't see this behavior 
> in PostgreSQL. Not sure how other RDBMS behave but it would be interesting 
> to compare.
>
> Peter
>

-- 
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 h2-database+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/h2-database/b0d4ff10-37a3-4181-aad6-aa9b10e598a0n%40googlegroups.com.

Re: [h2] A single update can 10x the filesize of the database

[Andrei Tokar]

Hi Alexander,
Your statement that "an UPDATE should not increase the filesize by 10x" is 
based on assumption that data is overwritten in-place, and it's definitely 
not the case.
It's not just H2, but I think any database with multi-version concurrency 
(or even any app using SSD, although this fact is hidden from us by OS file 
system).
How much slack is allowed and what the strategy should be to minimize it, 
is still an area of some development in H2, i.e. 
https://github.com/h2database/h2database/issues/3909.
As far as tuning goes, I would decrease RETENTION_TIME to 1000, or even 0 
(don't be scared by name, chunks are retained this days as long as needed, 
regardless), and do update in batches, as was already suggested.

Vincent,
Thank you for this thorough explanation, I think you assessment is 100% 
correct.

On Sunday, March 17, 2024 at 5:12:20 PM UTC-4 Vincent wrote:

> Hello,
>
> I am not a maintainer of H2 but I was curious and I have quickly looked at 
> your test case.
> If I print the filestore stats after the inserts/update, I think the 
> behavior is quite normal/expected actually.
>
> After the inserts, we have:
> info.FILL_RATE=100
> info.CHUNKS_FILL_RATE=99
> info.CHUNKS_FILL_RATE_RW=100
> info.CHUNK_COUNT=148
>
> Meaning the file is quite packed: No empty space in the file 
> (FILL_RATE=100%) and all chunks in the file are fully used (no dead pages, 
> CHUNKS_FILL_RATE=99%)
>
> Directly after the update:
> info.FILL_RATE=100
> info.CHUNKS_FILL_RATE=10
> info.CHUNKS_FILL_RATE_RW=100
> info.CHUNK_COUNT=1062
>
> As expected the number of chunks has greatly increased: The update takes a 
> while and the filestore autocommit is triggered regularly (after a very 
> small period of time or if pending changes size is bigger than a threshold, 
> cf. WRITE_DELAY, MVStore autoCommitBufferSize), creating a lot of new 
> chunks at the end of the file. -> Chunks fill rate has dropped to 10%, 
> meaning most of the chunks contain mostly dead pages. And that has explains 
> why you see a ~10 times file size increase btw.
>
> But then H2 has a background housekeeping that kicks in (after some time 
> because you use the default RETENTION_TIME of 45 sec. meaning it cannot 
> rewrite immediately the chunks).
> We end up with those stats:
> info.FILL_RATE=11
> info.CHUNKS_FILL_RATE=98
> info.CHUNKS_FILL_RATE_RW=99
> info.CHUNK_COUNT=223
>
> So H2 did rewrite most of the chunks and then deleted the chunks 
> containing only dead pages: There was a big decrease of the numbers of 
> chunks from 1062 containing mainly dead pages (CHUNK_FILL_RATE=10%) to 223 
> chunks with mainly alive pages (CHUNK_FILL_RATE=98%).
> Now the file contains a lot of "empty space" (FILL_RATE=11%), as dead 
> chunks are considered as free/empty space and alive chunks are probably at 
> the end of the file.
> That means that while the file remains quite large, any new chunks that 
> will be created will use the freed space and the file will not increase 
> anymore.
> After additional writes, you could even probably end up in a situation 
> where new chunks are written in the empty space at the beginning of the 
> file, freeing the chunks at the end of the file and that would trigger a 
> truncation of the file (=> file size reduction)
>
> In summary, it looks to me that H2 filestore is not designed/optimized to 
> keep the file as small as possible but it will somehow limit the file size 
> and make sure the space can be reused. If you really want to keep the file 
> size as minimal, I guess some tuning could be performed (mainly on 
> autocommit parameters ?).
>
> One of maintainer (Andrei Tokar ?) can probably share more on this topic 
> (and also assess whether what have explained in this comment is correct or 
> not :) )
>
> Best regards,
> Vincent
>
> Le dimanche 17 mars 2024 à 13:15:39 UTC+1, Alexander Kainz a écrit :
>
>> As I said I was able to avoid the issue, but figured a h2 db developer 
>> might want to know there is an issue.
>>
>> I think an UPDATE should not increase the filesize by 10x or the 
>> behaviour should at least be documented, I think.
>>
>>
>>
>> On Sunday 17 March 2024 at 14:13:36 UTC+7 Andreas Reichel wrote:
>>
>>> Greetings!
>>>
>>> Please try to either a) partitioning you update into smaller 
>>> chunks/commits or b) use a CTAS instead (although I am not a big fan of 
>>> this).
>>> Good luck
>>>
>>> Andreas
>>>
>>>
>>> On Sat, 2024-03-16 at 22:11 -0700, Alexander Kainz wrote:
>>>
>>> Hi,
>>>
>>> I wanted to mention this issue that took me

Re: [h2] Compact on db close does not shrink db file size

[Andrei Tokar]

Hi Ulrich,
Do you remove data in one big transaction? That would cause big transaction 
log to be created. I also agree with Noel's suggestion to insert data in 
batches.
As far as compaction goes, I would keep WRITE_DELAY at it's default (500), 
or even smaller (but positive) value. Apart from controlling how often 
auto-commit check runs, it also dictates how often background thread is 
trying to optimize file space by rewriting pages (evacuating pages from 
sparsely populated chunks) and compacting (moving chunks around). With high 
rate of inserts/updates auto-commit (not db commit, but chunk store 
operation) would happen anyway, once chunk reaches a certain size (around 1 
MB). WRITE_DELAY intended to handle cases with low update rates, when save 
should be triggered (even if new chunk is still small) to prevent data 
loss. So setting WRITE_DELAY to smaller value should intensify background 
file space housekeeping. If it's still not good enough for your case and 
you would like to go with periodic shut-downs, use SHUTDOWN COMPACT. This 
is a full database rewrite, and it's the best way to minimize disk space. 
Normal SHUTDOWN is limited by not only MAX_COMPACT_TIME, but also by 16MB 
of rewrites in size (not very helpful in your case).
On Tuesday, March 12, 2024 at 4:44:49 AM UTC-4 Noel Grandin wrote:

>
>
> On 3/12/2024 10:28 AM, Ulrich wrote:
> > 
> > My database has around 50.000 tables storing several 100 millions of 
> rows. Its a kind of time series database. Data is 
> > added continously (around 1500 rows per second) and data older than 30 
> days is removed once a day.
> > 
>
> I suggest (if you are not doing this already) that you move to an 
> architecture where instead of running DELETE when
> removing old data, you can run DROP TABLE or TRUNCATE TABLE, which will be 
> more efficient with H2.
>
> > As long as the automatic compaction did not show nice results I decided 
> to switch off the automatic compaction, set 
> > MAX_COMPACT_TIME to 3 and shutdown the database each 5 minutes using 
> SHUTDOWN. I use SHUTDOWN instead of SHUTDOWN 
> > COMPACT to get control over the maximum time while the db is not 
> available.
> > 
>
> Unfortunately SHUTDOWN just does not try very hard, if you want to reduce 
> disk space you will need to use SHUTDOWN COMPACT.
>
> H2 is unfortunately not a great match for your specific use-case, and I 
> don't think there is really anything in the way 
> of database parameters that will make a big difference.
>
> You could try batching your inserts (i.e. inserting a bunch of rows before 
> doing a COMMIT), that sometimes helps reduce 
> the disk usage.
>
> Regards, Noel.
>

-- 
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 h2-database+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/h2-database/6648566d-7e68-4d8c-994f-8b5333aff15en%40googlegroups.com.

Re: [h2] why insert many record to in-memory database is same speed as embedded-mode

[Andrei Tokar]

Apparently, you assumption about "In-mem should be much faster" is not 
correct.
It just makes me wonder, what exactly is the problem at hand? Is that the 
disk-based database is too fast?
Or there is an expectation of some "ludicrous speed" 
 for in-memory 
mode?  8-)
And if speed is not ludicrous enough - compare it with other databases out 
there. I am genuinely interested to see some results posted here.
Bottleneck most likely is memory manipulation, related to transactions 
management and non-blocking B-tree access (multi-version store).  Disk 
writes are done by parallel background threads, and it looks like, they are 
pretty much free (in this use case).
Some significant short-cuts can be taken under assumption of a 
single-client use (non-transactional, non-concurrent), but that is the 
topic for a wish list.

On Tuesday, January 9, 2024 at 8:26:58 AM UTC-5 mche...@gmail.com wrote:

> no, my program use 20 mins keep inserting to H2 (embed + in memory), both 
> speed become stable and nearly the same.
>
> On Tuesday 9 January 2024 at 01:30:44 UTC+8 Andreas Reichel wrote:
>
>> Because its cached and data are written to disk only eventually when the 
>> cache is full?
>>
>> On Mon, 2024-01-08 at 09:20 -0800, mche...@gmail.com wrote:
>>
>> hi.
>>why insert many record to in-memory database is same speed as 
>> embedded-mode. In-mem should be much faster, right?
>>
>>
>> import java.io.FileNotFoundException;
>> import java.io.IOException;
>> import java.sql.Connection;
>> import java.sql.DriverManager;
>> import java.sql.PreparedStatement;
>> import java.sql.SQLException;
>> import java.sql.Statement;
>> import me.tongfei.progressbar.ProgressBar;
>> import org.junit.Test;
>>
>> /**
>>  *
>>  * @author peter
>>  */
>> public class TestH2InsertSpeed {
>>
>> @Test
>> public void test() throws FileNotFoundException, IOException, 
>> SQLException {
>>
>> Connection conn = DriverManager.getConnection("jdbc:h2:./test;CACHE_SIZE=
>> 13107200 <310-7200>;PAGE_SIZE=10240;CACHE_TYPE=SOFT_LRU;", "sa", "");
>> // Connection conn = 
>> DriverManager.getConnection("jdbc:h2:mem:test;CACHE_SIZE=13107200 
>> <310-7200>;PAGE_SIZE=10240;CACHE_TYPE=SOFT_LRU;");
>> Statement stmt2 = conn.createStatement();
>> stmt2.execute("drop table if exists qemu;");
>> stmt2.execute("""
>>   CREATE TABLE "PUBLIC"."QEMU"
>>   (
>>  "ID" integer auto_increment PRIMARY KEY NOT NULL,
>>  "SEQUENCE" bigint,
>>  "DATE" timestamp,
>>  "COMPUTER" varchar(50),
>>  "INTERRUPT" boolean,
>>  "INTERRUPT_CAUSE" bigint,
>>  "INTERRUPT_DESC" varchar(30),
>>  "PC" bigint NOT NULL,
>>  "MHARTID" bigint NOT NULL,
>>  "MSTATUS" bigint NOT NULL,
>>  "HSTATUS" bigint NOT NULL,
>>  "VSSTATUS" bigint NOT NULL,
>>  "MIP" bigint NOT NULL,
>>  "MIE" bigint NOT NULL,
>>  "MIDELEG" bigint NOT NULL,
>>  "HIDELEG" bigint NOT NULL,
>>  "MEDELEG" bigint NOT NULL,
>>  "HEDELEG" bigint NOT NULL,
>>  "MTVEC" bigint NOT NULL,
>>  "STVEC" bigint NOT NULL,
>>  "VSTVEC" bigint NOT NULL,
>>  "MEPC" bigint NOT NULL,
>>  "SEPC" bigint NOT NULL,
>>  "VSEPC" bigint NOT NULL,
>>  "MCAUSE" bigint NOT NULL,
>>  "SCAUSE" bigint NOT NULL,
>>  "VSCAUSE" bigint NOT NULL,
>>  "MTVAL" bigint NOT NULL,
>>  "STVAL" bigint NOT NULL,
>>  "HTVAL" bigint NOT NULL,
>>  "MTVAL2" bigint NOT NULL,
>>  "MSCRATCH" bigint NOT NULL,
>>  "SSCRATCH" bigint NOT NULL,
>>  "SATP" bigint NOT NULL,
>>  "X0_ZERO" bigint NOT NULL,
>>  "X1_RA" bigint NOT NULL,
>>  "X2_SP" bigint NOT NULL,
>>  "X3_GP" bigint NOT NULL,
>>  "X4_TP" bigint NOT NULL,
>>  "X5_T0" bigint NOT NULL,
>>  "X6_T1" bigint NOT NULL,
>>  "X7_T2" bigint NOT NULL,
>>  "X8_S0" bigint NOT NULL,
>>  "X9_S1" bigint NOT NULL,
>>  "X10_A0" bigint NOT NULL,
>>  "X11_A1" bigint NOT NULL,
>>  "X12_A2" bigint NOT NULL,
>>  "X13_A3" bigint NOT NULL,
>>  "X14_A4" bigint NOT NULL,
>>  "X15_A5" bigint NOT NULL,
>>  "X16_A6" bigint NOT NULL,
>>  "X17_A7" bigint NOT NULL,
>>  "X18_S2" bigint NOT NULL,
>>  "X19_S3" bigint NOT NULL,
>>  "X20_S4" bigint NOT NULL,
>>  "X21_S5" bigint NOT NULL,
>>  "X22_S6" bigint NOT NULL,
>>  "X23_S7" bigint NOT NULL,
>>  "X24_S8" bigint NOT NULL,
>>  "X25_S9" bigint NOT NULL,
>>  "X26_S10" bigint NOT NULL,
>>  "X27_S11" bigint NOT NULL,
>>  "X28_T3" bigint NOT NULL,
>>  "X29_T4" bigint NOT NULL,
>>  "X30_T5" bigint NOT NULL,
>>  "X31_T6" bigint NOT NULL,
>>  "LINENO" bigint,
>>  "CODE" varchar(200),
>>  "MEM" boolean,
>>  "MEMOPERATION" varchar(200),
>>  "MEMREAD" boolean,
>>  "MEMADDR" bigint,
>>  "MEMVALUE" bigint,
>>  "MEMSIZE" integer,
>>  "CCODE" varchar(100),
>>  "PRIV" integer,
>>  "IRQREQUEST" boolean,
>>  "IRQREQUESTNO" integer,
>>  "IRQREQUESTLEVEL" 

[h2] Re: Infinite looping when trigger updates same table

[Andrei Tokar]

>From what you said, it sounds like a bug, but in order for someone to look 
at it, you need to provide a complete self-contained (without dependencies 
on any third party libraries) test case.

On Thursday, January 4, 2024 at 2:02:48 AM UTC-5 Gaus Lostre wrote:

> I create a trigger for automating the update timestamp column. That 
> trigger fires when a table is updated. Unfortunately, the trigger behaves 
> as an infinite loop when I use the sql command UPDATE.
> Can someone please help me? Is there a way for triggering once?
>

-- 
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 h2-database+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/h2-database/3edcc9c7-1498-408e-a994-8e9fedc9acc3n%40googlegroups.com.

[h2] Re: out of memory after executeBatch

[Andrei Tokar]

Hi Peter,
It is really hard to tell exactly what the problem with your code is, 
because it is not a complete one, but in case of OOM some "irrelevant" 
details may be a culprit.
Nevertheless, it looks like "data" is some sort of a queue, continuously 
populated by another thread, or just a big chunk of preropulated data?
In both cases your condition for batch commit (data.size() % 10 == 0 || 
data.size() < 10) looks suspicious. Let's assume prepopulated data of 
size 
10 * 12345 +1
You may end up committing batch of size 1.2 billion+, wchich would totally 
explain OOM..

On Tuesday, November 21, 2023 at 5:41:30 AM UTC-5 mche...@gmail.com wrote:

> Dear All
> I keep clicking the data to h2 by stmt.addBatch(), after i called 
> executeBatch, memory is not free, so finally out of memory, may i know why 
> please?
>
>
> @Override
> public void run() {
> while (!stopped) {
> synchronized (sharedLock) {
> try {
> // System.out.println("data.size() =" + data.size());
> for (int z = 0; z < data.size() && z < 10; z++) {
> Object[] temp;
> synchronized (data) {
> temp = data.pollLast();
> }
> int x = 1;
> stmt.setLong(x++, (Long) temp[0]);
> stmt.setString(x++, (String) temp[1]);
> stmt.setString(x++, (String) temp[2]);
> stmt.setString(x++, (String) temp[3]);
> stmt.setInt(x++, (int) temp[4]);
> for (int tempX = 0; tempX < registers.size(); tempX++) {
> stmt.setLong(x, ((BigInteger) temp[x - 1]).longValue());
> x++;
> }
> stmt.addBatch();
> }
> if (data.size() % 10 == 0 || data.size() < 10) {
> stmt.executeBatch();
> conn.commit();
> }
> } catch (SQLException ex) {
> Logger.getLogger(H2Thread.class.getName()).log(Level.SEVERE, null, ex);
> }
> }
> try {
> Thread.sleep(500);
> } catch (InterruptedException ex) {
> Logger.getLogger(H2Thread.class.getName()).log(Level.SEVERE, null, ex);
> }
> }
> }
>
> thanks
> Peter (mche...@hotmail.com)
>

-- 
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 h2-database+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/h2-database/0c138c38-ba35-4543-a4e3-45e9cbc4ccf8n%40googlegroups.com.

[h2] H2 Database Engine: New version released

[Andrei Tokar]

Hello Everybody,

A new version 2.2.224 of H2 is available at http://www.h2database.com
(you may have to click 'Refresh').

This is a patch release, and there are no incompatibilities with
on-disk format of v.2.2.222, so it can be used as drop in
replacement for 2.2.222. 

It will be available in Maven repository shortly.

For details, see the 'Change Log' at
http://www.h2database.com/html/changelog.html

P.S. If you reply to this message please use a different subject.

Have fun,
Andrei Tokar

-- 
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 h2-database+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/h2-database/356040df3219c8cd1e1af5170e2c42ff34a43d62.camel%40gmail.com.

[h2] Re: It is my pleasure to present some transaction-testing code...

[Andrei Tokar]

Hi Ronery Coder,
I haven't had a time to look at your code yet, but any tests are very match 
appreciated, of course. 
In a meantime, here are my 2c on your report from the implementer point of 
view:

#1,2 Absence of the phenomena at particular level does not mean that 
implementation is wrong, just MAYBE inefficient. In case of H2, 
multi-version nature of it allows for a cheap snapshot (at the start of a 
transaction for REPEATABLE_READ, or at the start of a SQL statement for 
READ_COMMITTED), which would indeed prevent any "phantom read". If you can 
come up with implementation, which would benefit from allowing phantom 
reads, your patch is welcome.
#3 As you said, "This should probably be fixed at the Spring level."
#4 It is correct In NON_REPEATABLE_READ mode, because T1 updated X, so T2 
may see at different times (diferent statements with tx) committed value of 
X, or previous one. Since transactions are concurrent, T2's read may be not 
repeatable.
In READ_COMMITTED mode your scenario should cause NO exceptions.
But In any case, it's not a deadlock. For a deadlock you need at least two 
records to be updated by T1 and T2 in different order. It you have an 
example of a deadlock exception in a different scenario, please let me know.


On Friday, September 1, 2023 at 10:29:41 AM UTC-4 Ronery Coder wrote:

> And stupidly I forgot the link to the github project. Here it is:
>
> https://github.com/dtonhofer/testing_h2_and_spring_jdbc
>
> On Friday, September 1, 2023 at 2:48:44 PM UTC+2 Ronery Coder wrote:
>
>> Good day!
>>
>> I burned some time to write Java code which tests H2 database transaction 
>> behaviour through Spring Data JDBC. Well documented. Nothing particularly 
>> complex or groundbreaking, just JUnit tests to experiment with. This may be 
>> of interest to people who want to do their own tests.
>>
>> This project contains the tests, along with two other subjects, namely an 
>> exercise involving agents who communicate via the H2 database and an 
>> exercise that verifies that Java Instants are indeed properly stored and 
>> retrieved.
>>
>> What to report on the exploration of transactions:
>>
>>
>>1. I have been unable to generate the "Phantom Read" phenomenon in 
>>isolation level ANSI "REPEATABLE READ" . This may be because H2 
>>preventatively nixes it at that level, where it is supposed to still 
>> occur. 
>>It's possible, depending on how transactions are implemented. Or I just 
>>don't use a predicate that is complex enough.
>>2. Trying to elicit "Non-Repeatable Read" and "Phantom Read" 
>>phenomena at isolation level ANSI "READ COMMITTED", we find that the 
>>phenomena are unexpectedly *absent* in ~0.18% of cases, apparently 
>>randomly: H2 implements stronger transactions than expected. I *don't* 
>>think it is my test code that is the reason, but then again, I'm not sure.
>>3. There is some problem in Spring Data JDBC "translating" an 
>>`org.h2.jdbc.JdbcSQLTimeoutException`, leading to the user code receiving 
>> a 
>>confusing `org.springframework.transaction.TransactionSystemException` 
>> with 
>>the message `JDBC rollback failed`. This should probably be fixed at the 
>>Spring level.
>>4. H2 is quite radical in generating "deadlock exceptions" 
>>(`org.h2.jdbc.JdbcSQLTransactionRollbackException`). As long as two 
>>transaction T1 and T2 were active concurrently, T1 wrote X, then 
>> committed 
>>and T2 read or wrote _something_ then (after T1's commit), writes X too, 
>> a 
>>deadlock is detected. If I reflect on what could go wrong in such 
>>scenarios, I don't see the reason for throwing. Is H2 just extremely 
>>pessimistic/conservative?
>>
>>
>>
>>

-- 
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 h2-database+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/h2-database/d5738b60-946a-4ea2-a749-309dd6e8b9ebn%40googlegroups.com.

[h2] Re: Version 2.2.222 still not available in the Maven repository

[Andrei Tokar]

Manfred, 
It was just uploaded to repository by Thomas Müeller .

Jürgen, Andreas,
I was able to replicate your performance problem, and filed a test case in H2 
issue tracker. <https://github.com/h2database/h2database/issues/3883>

On Friday, September 1, 2023 at 5:05:38 AM UTC-4 Manfred Rosenboom wrote:

> Hi Andrei,
>
> As far as I got it, the version 2.2.222 is an important patch to version 
> 2.2.220, but it is still not available in the Maven repository. So please 
> add this version to the repository.
>
> Best and many thanks in advance
> Manfred
>
>
> Andrei Tokar schrieb am Mittwoch, 23. August 2023 um 14:09:56 UTC+2:
>
> Hello Everybody, 
>
> A new version 2.2.222 of H2 is available at http://www.h2database.com 
> (you may have to click 'Refresh'). 
>
> This is a patch release, and AFAIK there are no incompatibilities with 
> on-disk format of v.2.2.220, so hopefully it can be used as drop in 
> replacement for 2.2.220 (and only 2.2.220!). 
>
> It will be available in Maven repository shortly. 
>
> For details, see the 'Change Log' at 
> http://www.h2database.com/html/changelog.html 
>
> P.S. If you reply to this message please use a different subject. 
>
> Have fun, 
> Andrei Tokar 
>
>

-- 
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 h2-database+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/h2-database/f031456d-b6f8-4af3-96a8-c5b5dd1592cbn%40googlegroups.com.

[h2] H2 Database Engine: New version released

[Andrei Tokar]

Hello Everybody,

A new version 2.2.222 of H2 is available at http://www.h2database.com
(you may have to click 'Refresh').

This is a patch release, and AFAIK there are no incompatibilities with
on-disk format of v.2.2.220, so hopefully it can be used as drop in
replacement for 2.2.220 (and only 2.2.220!). 

It will be available in Maven repository shortly.

For details, see the 'Change Log' at
http://www.h2database.com/html/changelog.html

P.S. If you reply to this message please use a different subject.

Have fun,
Andrei Tokar

-- 
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 h2-database+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/h2-database/a474a189bdf421aeb5807360e8e483a31ccb2acc.camel%40gmail.com.

[h2] Re: 2.2.220: File corrupted in chunk 17, expected page length 4..1536, got -1711276031 [2.2.220/6]

[Andrei Tokar]

Thanks a lot t603 for a quick turnaround. Since it fixes your issue, test 
case is not really needed, Now we are good to issue a new release.
-- Andrei

On Tuesday, August 22, 2023 at 2:01:53 PM UTC-4 t603 wrote:

> Hi, Andrei, 
> You are great, *You have fixed the problem*! I have built the 
> h2-2.2.229-SNAPSHOT.jar with Adoptium OpenJDK 17 (the same Java, which I 
> use for my app), run my code twice and it works both times without error!
> Unfortunately I can not share data, because all data are taken runtime 
> from external linked tables mostly to another databases and from CSV and 
> JSON a XML datasources. 
> Thank You very much, Stepan 
>
> Dne úterý 22. srpna 2023 v 16:36:52 UTC+2 uživatel Andrei Tokar napsal:
>
>> Hi t603,
>> I think I have a fix for corruption problem, but since I can not 
>> reproduce it myself, and you are claiming that you have a reproducible test 
>> case, it will be extremely helpful if you can build H2 from master branch, 
>> as outlined here <https://h2database.com/html/build.html#building> and 
>> confirm the fix (or not), so we can accordingly plan the patch or keep 
>> digging.
>> If you, on the other hand, can share your test case with mangled data (if 
>> sensitive), that would be even better, especially if my fix is not good 
>> enough.
>> --
>> Thank You,
>> Andrei Tokar
>>
>

-- 
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 h2-database+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/h2-database/9975752d-5e3e-4c1a-b3a7-7839ecdbdda0n%40googlegroups.com.

[h2] Re: 2.2.220: File corrupted in chunk 17, expected page length 4..1536, got -1711276031 [2.2.220/6]

[Andrei Tokar]

Hi t603,
I think I have a fix for corruption problem, but since I can not reproduce 
it myself, and you are claiming that you have a reproducible test case, it 
will be extremely helpful if you can build H2 from master branch, as 
outlined here <https://h2database.com/html/build.html#building> and confirm 
the fix (or not), so we can accordingly plan the patch or keep digging.
If you, on the other hand, can share your test case with mangled data (if 
sensitive), that would be even better, especially if my fix is not good 
enough.
--
Thank You,
Andrei Tokar

-- 
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 h2-database+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/h2-database/38e85aa1-3d65-427d-9bd7-5c5cd59a34d4n%40googlegroups.com.

[h2] H2 Database Engine: New version released

[Andrei Tokar]

Hello,

A new version 2.2.220 of H2 is available at http://www.h2database.com
(you may have to click 'Refresh') and
https://github.com/h2database/h2database/releases/tag/version-2.2.220


For details, see the 'Change Log' at
http://www.h2database.com/html/changelog.html

New artefacts will be uploaded to maven repository shortly.


Have fun,
Andrei Tokar


-- 
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 h2-database+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/h2-database/baa7598e652f5e0f469b2706f8e990dd4b32ac31.camel%40gmail.com.

[h2] Re: Error reading existing databases with H2 trunk

[Andrei Tokar]

Hi Silvio,
SQL dump / restore is the only supported way to transition from one version 
to the other. 
We are making our best trying to preserve compatibility with older db 
files, but again, it's on a "best effort" basis.
Forward compatibility is totaly out of question. 
And that's I've been talking about released versions. Jumping onto 
unreleased version is totally "leap of faith", should be no expectations 
about switching back, or compatibility with future released version. SQL 
dump/restore should work most of the time though.


On Tuesday, June 13, 2023 at 5:45:10 AM UTC-4 Silvio wrote:

> Hello all,
>
> I created a H2 test build from current trunk. Using this on a bunch of 
> databases created with 2.1.214 I get the following error on a rather large 
> part of them:
>
> org.h2.mvstore.MVStoreException: File is corrupted - unable to recover a 
> valid set of chunks [2.2.219/6]
>
> When reverting to 2.1.214 the problem disappears.
>
> Do databases have to be dumped/restored for this to work properly? Or is 
> 2.2.219 supposed to be able to use databases created with 2.1.214?
>
>
>

-- 
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 h2-database+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/h2-database/9fff1b95-1a54-4767-9abb-23c17ebb4ecfn%40googlegroups.com.

Re: [h2] In-Memory H2 deleted rows not garbage collected.

[Andrei Tokar]

And to confirm that problem is still there, please run it against at least 
latest released version (2.1.214), or even better against current git build.
I have that feeling that you just run queries with LOB in the result which 
causes extensive LOB cloning. Try to add ;LOB_TIMEOUT=1000 (1 sec instead 
of default 5 min)
.
On Monday, May 22, 2023 at 2:45:23 AM UTC-4 Andreas Reichel wrote:

> Greetings!
>
> On Sun, 2023-05-21 at 23:42 -0700, Arjun Sahoo wrote:
>
> Reproducing the test case is easy, keep on ingesting and deleting records, 
> you will see the memory usage increasing over time. If if query the table 
> simultaneously , you will reach the trend faster.
>
>
>
> You will need to write a self containing unit test simulating this, Only 
> this way people will help ypu.
>
> Best regards
> Andreas
>

-- 
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 h2-database+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/h2-database/84e85db2-fc01-4e92-a4d2-6e162ec3a30bn%40googlegroups.com.

[h2] Re: Asking for help

[Andrei Tokar]

Your test will pass if last view will be defined as (please note placement 
of join conditions):
CREATE VIEW VW_INVOICESUMMARY AS
SELECT IL.INV_ID,
   ROUND(SUM(IL.QUANTITY * IL.RATE), 2) AS NETTOT,
   ROUND(SUM(IL.VATVAL), 2) AS VATTOT,
   ROUND(SUM(IL.QUANTITY * IL.RATE) + SUM(IL.VATVAL), 2) AS 
GROSSTOT,
   B.DESC AS DESC,
   B.YEARREL AS RELEVANT_YEAR,
   B.RAISED AS RAISED,
   B.DUE AS DUE,
   B.JURISID AS JURISID,
   C.ID AS ACTID,
   C.NAME AS ACTNAME,
   D.ID AS ORGID,
   D.NAME AS ORGNAME
FROM VW_INVOICELINES IL
INNER JOIN TB_INVOICE B ON IL.INV_ID = B.ID
INNER JOIN TB_ACTIVITY C ON B.ACTID = C.ID
INNER JOIN TB_ORG D ON C.ORGID = D.ID
GROUP BY IL.INV_ID


On Wednesday, February 8, 2023 at 6:08:20 AM UTC-5 Jim Foster wrote:

> Hi, 
>
> My financial database has stopped working and I don't have any idea why.  
> When creating a view, I get a syntax error saying a column can't be found 
> even though I can see it there.  It worked fine last time I ran it and 
> after a lot of playing round I can't get it working again.
>
> I hacked out the code into a test class, which also fails.  The code is:
> public class DBTst
> {
>
>   public static void main(String[] args) throws SQLException
>   {
> //JdbcConnectionPool cp = JdbcConnectionPool.create("jdbc:h2:mem:db1", 
> "sa", "");
> 
> // Set up the database.
> try (Connection cn = DriverManager.getConnection("jdbc:h2:mem:db1", 
> "sa", ""))
> {
>   // Make sure not autocommit.
>   cn.setAutoCommit(false);
>
>   // Create DB structure.
>   //
>   // Create the tables.
>   try (Statement st = cn.createStatement())
>   {
> // Organisations table.
> st.execute("CREATE TABLE TB_ORG ( ID IDENTITY, NAME VARCHAR NOT 
> NULL, ABBREV VARCHAR NOT NULL, TYPE INTEGER NOT NULL)");
>
> // Activity table.
> st.execute("CREATE TABLE TB_ACTIVITY ( ID IDENTITY (35), NAME 
> VARCHAR NOT NULL, CUSTREF VARCHAR NOT NULL, ORGID INTEGER NOT NULL, FOREIGN 
> KEY (ORGID) REFERENCES TB_ORG(ID))");
>
> // Invoice table.
> st.execute("CREATE TABLE TB_INVOICE (ID IDENTITY(114), DESC 
> VARCHAR NOT NULL, YEARREL INTEGER NOT NULL, RAISED DATE NOT NULL, DUE DATE 
> NOT NULL, JURISID INTEGER NOT NULL, ACTID INTEGER NOT NULL, FOREIGN KEY 
> (ACTID) REFERENCES TB_ACTIVITY(ID) )");
>
> // Event line table.
> st.execute("CREATE TABLE TB_EVENTLINE(ID IDENTITY, DESC VARCHAR 
> NOT NULL, QUANTITY NUMERIC(100,2) NOT NULL, RATE NUMERIC(100,2) NOT NULL, 
> VATVAL NUMERIC(100,2))");
>
> // Invoice line table.
> st.execute("CREATE TABLE TB_INVOICETRANSACTIONLINE (INVID INTEGER 
> NOT NULL, EVLID INTEGER NOT NULL, FOREIGN KEY (INVID) REFERENCES 
> TB_INVOICE(ID), FOREIGN KEY (EVLID) REFERENCES TB_EVENTLINE(ID))");
>
> 
> //setupQueries
> //VIEWS
> 
> //Invoice lines
> st.execute("CREATE VIEW VW_INVOICELINES AS SELECT A.INVID AS 
> INV_ID, A.EVLID AS EVLID, B.DESC AS DESC, B.QUANTITY AS QUANTITY, B.RATE AS 
> RATE, ROUND(B.QUANTITY * B.RATE, 2) AS NETTOT, B.VATVAL AS VATVAL, FROM 
> TB_INVOICETRANSACTIONLINE A INNER JOIN TB_EVENTLINE B ON A.EVLID = B.ID");
> 
> System.out.println("Invoice lines view:");
> ResultSet executeQuery = st.executeQuery("SELECT * FROM 
> VW_INVOICELINES ");
> printResults(executeQuery);
>
> System.out.println("Invoice table:");
> executeQuery = st.executeQuery("SELECT * FROM TB_INVOICE ");
> printResults(executeQuery);
> 
> System.out.println("Activity table:");
> executeQuery = st.executeQuery("SELECT * FROM TB_ACTIVITY ");
> printResults(executeQuery);
>
> System.out.println("Organisations table:");
> executeQuery = st.executeQuery("SELECT * FROM TB_ORG ");
> printResults(executeQuery);
>
> //Invoice summary
> System.out.println("Invoice summary view:");
> st.execute("CREATE VIEW VW_INVOICESUMMARY AS SELECT IL.INV_ID, 
> ROUND(SUM(IL.QUANTITY * IL.RATE), 2) AS NETTOT, ROUND(SUM(IL.VATVAL), 2) AS 
> VATTOT, ROUND(SUM(IL.QUANTITY * IL.RATE) + SUM(IL.VATVAL), 2) AS GROSSTOT, 
> B.DESC AS DESC, B.YEARREL AS RELEVANT_YEAR, B.RAISED AS RAISED, B.DUE AS 
> DUE, B.JURISID AS JURISID, C.ID AS ACTID, C.NAME AS ACTNAME, D.ID AS 
> ORGID, D.NAME AS ORGNAME FROM VW_INVOICELINES IL INNER JOIN TB_INVOICE B 
> INNER JOIN TB_ACTIVITY C INNER JOIN TB_ORG D ON IL.INV_ID = B.ID AND 
> B.ACTID = C.ID AND C.ORGID = D.ID GROUP BY IL.INV_ID");
>
> // Commit.
> cn.commit();
>   }
>
> }
>   }
>   
>   public static void printResults(ResultSet rs) throws SQLException
>   {
> StringBuilder sb = new StringBuilder();
> 
> // Top line - the column names.
> for(int i = 0; i < rs.getMetaData().getColumnCount(); i++)
> 

[h2] Re: questions about case sensitivity

[Andrei Tokar]

Hi Andy,

I wonder, what are your expectations in such scenario?
If you are looking for a way to shoot yourself in the foot, I am sure H2 
will present multiple opportunities for that.
Does it really matter if it end up with "table not found" or will select 
from one or the other table, at random?
Of course, you are always welcome to try...

On Saturday, January 14, 2023 at 10:38:13 PM UTC-5 AndyGo wrote:

> Thanks. Appreciate the quick and comprehensive response. Can you explain 
> this a bit more: "It is possible to specify them in the default Regular 
> compatibility mode "
>
> Just curious, since the settings can't persist... what would happen if, in 
> default mode, I created MyTable and also "mytable" and then later, 
> connected with CASE_INSENSITIVE_IDENTIFIERS and queried SELECT * FROM 
> MYTABLE ?
>
> On Friday, January 13, 2023 at 2:12:31 AM UTC-8 Evgenij Ryazanov wrote:
>
>> Hello!
>>
>> These settings aren't related to each other.
>>
>> IGNORE_CASE is about *data types* and their *values*. It replaces CHARACTER 
>> VARYING (VARCHAR) columns in DDL commands with VARCHAR_IGNORECASE data 
>> type. This legacy setting should never be used, it is much better to 
>> specify some case-insensitive database collation if you need it.
>>
>> DATABASE_TO_UPPER, DATABASE_TO_LOWER, and CASE_INSENSITIVE_IDENTIFIERS 
>> settings change treatment of *identifiers*. H2 by default is fully 
>> compliant with the SQL Standard here. It means all unquoted identifiers are 
>> converted to upper case. id, ID, Id, "ID" (and also non-standard 
>> MySQL-style `ID` and `id`) are equal to each other, but "id" is an 
>> another identifier. Some other database systems historically process 
>> identifiers in their own special way and sometimes this way also depends on 
>> their environment. That's why these settings can be set separately from 
>> compatibility modes. Values of these settings, however, aren't persisted 
>> and you must always specify them with the same values in JDBC URL.
>>
>> It is possible to specify them in the default Regular compatibility mode 
>> too, but, again, the default behavior is already correct and compliant with 
>> the Standard.
>>
>

-- 
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 h2-database+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/h2-database/3d6ca12e-19f4-43f9-884b-23e3b28661d5n%40googlegroups.com.

[h2] Re: Using mvstore directly, is there a way to mark a map as readonly

[Andrei Tokar]

I think the answer is "no" on both points. Currently here is no API to 
declare particular map read-only, and there is no way to disable caching of 
data for particular map, since it cached at lower level. I wonder what 
benefits do you expect from that? 

On Tuesday, December 20, 2022 at 3:28:54 PM UTC-5 dfgood...@googlemail.com 
wrote:

> I have a database which uses mvstore directly (no sql).  It has three maps 
> in it, one of which is only ever loaded when I create the database.  I 
> always close the database between writing this first table and subsequent 
> runs when I am just reading the table. The other two tables are written and 
> read.  
>
> In all cases I do not need the data read from the database cached for 
> re-read, as I convert the data read from the database into internal 
> structures which I keep anyway.
>
> Is there any way to tell mvstore that my first table is readonly after the 
> first run, and will it help?
>
> Also is there a way to tell mvstore not to bother caching read results, 
> and again will it help?
>

-- 
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 h2-database+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/h2-database/9fd6f87c-e1d1-478d-ace6-98332bbf56a6n%40googlegroups.com.

[h2] Re: Wrong Discription on Download for Distribution "1.4.202"

[Andrei Tokar]

It was already fixed in the repository, just never made it to the actual 
site. Uploaded now.
Thanks for reporting and I am sorry about any inconvenience.

On Wednesday, November 2, 2022 at 8:28:34 AM UTC-4 heiko.sa...@gmail.com 
wrote:

> I need so open an old embeddad database in h2-format (*.h2.db). So I need 
> the parameter "mv_store=false" in connection string. The support of this 
> old h2-format and the paramter H2 has ended with version 1.4 and versions 
> 2.*.* support only the MVStore-based fortmat.
>
> So I downloaded the latest version 1.4 on 
> http://www.h2database.com/html/download-archive.html
>
> After several error messages like 
>
> General error: "java.lang.UnsupportedOperationException" [5-202] 
> HY000/5
>
> I found out that the download of Distribution "1.4.202" is containing 
> version "2.0.202" that does not support the old h2-format and the paramter 
> "mv_store=false".
>
> [image: Download-Dist-1.4.202-contains-2.0.202.png]
>
> Who could be informed to change that discription on 
> http://www.h2database.com/html/download-archive.html ???
>
>

-- 
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 h2-database+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/h2-database/b2de1ae6-d8d5-4aba-8afa-3d2b9cf5873fn%40googlegroups.com.

[h2] Re: LOB_TIMEOUT not working

[Andrei Tokar]

Hi David,

Are you sure that you are reading the latest (2.1.214) code? There is no 
MVStore.notifyAboutOldestVersion() anymore.
Please make ALL of your testing with 2.1.214, since the area of interest 
was actively modified recently.

Regards,
Andrei

On Thursday, August 4, 2022 at 11:06:53 AM UTC-4 david@gmail.com wrote:

> Hello,
>
> I made a simple testcase that shows that LOB_TIMEOUT is not working.
> See the attachment. Testcase creates an in-memory db with table with clob 
> column, inserts 2048 records with 1MB clob. After GC, heap is at 2.2GB. 
> Selecting test table for 5000 times increases heap to 4.2GB. After 
> LOB_TIMEOUT=5s nothing happens. Closing connection helps somehow, but maybe 
> because of other reasons.
> Tested mainly on v2.1.212, but also on 2.1.214, and 1.4.199.
>
> Looking at H2 code, resultset LOBs get registered to 
> LobStorageMap#pendingLobRemovals. These are removed in 
> LobStorageMap.cleanup(). This method is called from 
> MVStore.notifyCleaner(), and this one from MVStore.closeStore() and from 
> MVStore.notifyAboutOldestVersion(). The notifyAboutOldestVersion() starts 
> with if containing the 'bufferSaveExecutor != null' condition. But 
> bufferSaveExecutor is only set to non-null value in 
> setAutoCommitDelay(millis) where millis>0. Debugger shows it as null, so 
> cleanup isnt executed.
>
> Am I right?
>
> Teporary solution was to set MAX_LENGTH_INPLACE_LOB=. I 
> assume for in-memory DBs high MAX_LENGTH_INPLACE_LOB values are ok. This 
> solves the heap issues, and makes inserts and selects much much faster. In 
> is also easily applicable, no code fixes, just url update.
>
> Thank you, H2 is still great!
>
> David.
>
>
>
>
>

-- 
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 h2-database+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/h2-database/a1dfb328-aaae-4f03-8281-2236b41c5320n%40googlegroups.com.

[h2] Re: H2 version 2.1.210 droping public table on its own

[Andrei Tokar]

I am curious what might be the reason to try the addition of  
MV_Store=FALSE to your connection URL, 
but that option has been removed a while ago (at v. 1.4.200 ?), and MVStore 
is the only storage engine available in H2.

On Monday, July 11, 2022 at 11:43:47 AM UTC-4 ronjos...@gmail.com wrote:

> Hello ,
>
> I am working with the H2 2.1.214 and I want to add MV_Store=FALSE to my 
> JDBC Connection string.
> can you please tell me how its done ?
>
> Currently I am adding it 
> 
>  
> jdbc:h2:file:databasePath/dbName;MV_STORE=FALSE;LOCK_TIMEOUT=180;MAX_COMPACT_TIME=1
>  
> and it is giving me ' General error: 
> "java.lang.UnsupportedOperationException"'.
> Thanks
> On Thursday, June 23, 2022 at 10:44:43 AM UTC+5:30 kapoor.s...@gmail.com 
> wrote:
>
>> I have some more logs. please see below
>>
>>
>> 2022-06-23 08:43:23 database: disconnecting session #3
>> 2022-06-23 08:43:23 database: closing /Volumes/Macintosh HD - 
>> Data/Projects/informixhq-server/server/h2db
>> 2022-06-23 08:43:23 lock: 2 shared read unlock SYS 
>> 2022-06-23 08:43:23 lock: 1 shared read unlock SYS 
>> 2022-06-23 08:43:23 database: closed
>> 2022-06-23 08:43:23 database: disconnected session #3
>> 2022-06-23 08:43:23 database: opening /Volumes/Macintosh HD - 
>> Data/Projects/informixhq-server/server/h2db (build 210)
>> 2022-06-23 08:43:23 lock: 1 exclusive requesting for SYS 
>> 2022-06-23 08:43:23 lock: 1 exclusive added for SYS 
>> 2022-06-23 08:43:23 lock: 1 exclusive requesting for 
>> INFORMIX_SERVER_GROUPS 
>> 2022-06-23 08:43:23 lock: 1 exclusive added for INFORMIX_SERVER_GROUPS 
>> 2022-06-23 08:43:23 lock: 1 exclusive requesting for SYSTEM_REPORTS 
>> 2022-06-23 08:43:23 lock: 1 exclusive added for SYSTEM_REPORTS 
>> 2022-06-23 08:43:23 lock: 1 exclusive requesting for ALERTING_INCIDENTS 
>> 2022-06-23 08:43:23 lock: 1 exclusive added for ALERTING_INCIDENTS 
>> 2022-06-23 08:43:23 lock: 1 exclusive requesting for USERS 
>> 2022-06-23 08:43:23 lock: 1 exclusive added for USERS 
>> 2022-06-23 08:43:23 lock: 1 exclusive requesting for SENSOR_TYPES 
>> 2022-06-23 08:43:23 lock: 1 exclusive added for SENSOR_TYPES 
>> 2022-06-23 08:43:23 lock: 1 exclusive requesting for 
>> ALERTING_CRITERIA_VIOLATIONS 
>> 2022-06-23 08:43:23 lock: 1 exclusive added for 
>> ALERTING_CRITERIA_VIOLATIONS 
>> 2022-06-23 08:43:23 lock: 1 exclusive requesting for USER_PERMISSIONS 
>> 2022-06-23 08:43:23 lock: 1 exclusive added for USER_PERMISSIONS 
>> 2022-06-23 08:43:23 lock: 1 exclusive requesting for 
>> USER_ALERT_MESSENGERS 
>> 2022-06-23 08:43:23 lock: 1 exclusive added for USER_ALERT_MESSENGERS 
>> 2022-06-23 08:43:23 lock: 1 exclusive requesting for DASHBOARDS 
>> 2022-06-23 08:43:23 lock: 1 exclusive added for DASHBOARDS 
>> 2022-06-23 08:43:23 lock: 1 exclusive requesting for USER_ALERT_SERVICES 
>> 2022-06-23 08:43:23 lock: 1 exclusive added for USER_ALERT_SERVICES 
>> 2022-06-23 08:43:23 lock: 1 exclusive requesting for INFORMIX_SERVERS 
>> 2022-06-23 08:43:23 lock: 1 exclusive added for INFORMIX_SERVERS 
>> 2022-06-23 08:43:23 lock: 1 exclusive unlock SYS 
>> 2022-06-23 08:43:23 lock: 1 exclusive unlock INFORMIX_SERVER_GROUPS 
>> 2022-06-23 08:43:23 lock: 1 exclusive unlock SYSTEM_REPORTS 
>> 2022-06-23 08:43:23 lock: 1 exclusive unlock ALERTING_INCIDENTS 
>> 2022-06-23 08:43:23 lock: 1 exclusive unlock USERS 
>> 2022-06-23 08:43:23 lock: 1 exclusive unlock SENSOR_TYPES 
>> 2022-06-23 08:43:23 lock: 1 exclusive unlock ALERTING_CRITERIA_VIOLATIONS 
>> 2022-06-23 08:43:23 lock: 1 exclusive unlock USER_PERMISSIONS 
>> *2022-06-23 08:43:23 lock: 1 exclusive unlock USER_ALERT_MESSENGERS *
>> 2022-06-23 08:43:23 lock: 1 exclusive unlock DASHBOARDS 
>> 2022-06-23 08:43:23 lock: 1 exclusive unlock USER_ALERT_SERVICES 
>> 2022-06-23 08:43:23 lock: 1 exclusive unlock INFORMIX_SERVERS 
>> 2022-06-23 08:43:23 database: opened /Volumes/Macintosh HD - 
>> Data/Projects/informixhq-server/server/h2db
>> 2022-06-23 08:43:23 database: connecting session #3 to /Volumes/Macintosh 
>> HD - Data/Projects/informixhq-server/server/h2db
>> 2022-06-23 08:43:23 jdbc[3]: 
>> /*SQL */SET TRACE_LEVEL_FILE 3;
>> 2022-06-23 08:43:23 jdbc[3]: 
>> /**/Connection conn2679 = 
>> DriverManager.getConnection("jdbc:h2:file:./h2db;TRACE_LEVEL_FILE=3", "", 
>> "");
>> 2022-06-23 08:43:23 jdbc[3]: 
>> /**/PreparedStatement prep947 = conn2679.prepareStatement("update 
>> informix_servers set alias = ?, hostname = ?, service_name = ?, port = ?, 
>> monitor_user = ?, monitor_password = ?, admin_user = ?, admin_password = ?, 
>> group_id = ?, profile = ?, alerts = ?, properties = ?, agent_config = ?, 
>> password_secret_Key = ?, server_type = ? where id = 11");
>> 2022-06-23 08:43:23 jdbc[3]: Table  : potential plan item cost 
>> 10,390 index PUBLIC.INFORMIX_SERVERS.tableScan
>> 2022-06-23 08:43:23 jdbc[3]: Table  : potential plan item cost 
>> 230 index PUBLIC.PRIMARY_KEY_3
>> 2022-06-23 08:43:23 jdbc[3]: 
>> /**/prep947.setString(1, "FUN1");
>> 202

Re: [h2] Automatic COMPACT does not seem to work

[Andrei Tokar]

Yes, it makes sense now to make RETENTION_TIME=0 as a default. Use case for 
a positive value is that it theoretically improve your chances for recovery 
in case of abrupt shutdown (more history has been kept), but that's about 
it. This setting does not change the way how compaction works, it just 
delays marking chunks of storage as available for reuse. Database might be 
little faster, because there is less garbage to shuffle around, pretending 
it's still a data. Current default (45 sec) seems a way too high.

On Friday, June 24, 2022 at 4:23:54 AM UTC-4 Ulrich wrote:

> Using RETENTION_TIME=0, I see that a moderate compaction is applied :-) 
> That's completely sufficient!
> I'll now check how it behaves in long term.
>
> RETENTION_TIME=0 also speeds up the database significantly. 
> Is there any use case to set RETENTION_TIME>0? Should the default value be 
> changed in H2?
>
> andrei...@gmail.com schrieb am Donnerstag, 23. Juni 2022 um 03:22:44 
> UTC+2:
>
>> Documentation is outdated. At the time, garbage determination was inexact 
>> and this was used as additional safety. This is not the case since 1.4.197 
>> or 1.4.198, premature storage release is not possible anymore. 
>>
>> On Wednesday, June 22, 2022 at 9:17:39 AM UTC-4 Ulrich wrote:
>>
>>> The documentation says:
>>> Using a lower value might be dangerous, unless the file system and hard 
>>> disk flush the buffers earlier. 
>>>
>>> Is it safe to use RETENTION_TIME=0? What are the consequences?
>>> Do I have to fear that the database file becomes corrupted or that 
>>> transactions are not consistent?
>>>
>>> I would rather try to add RETENTION_TIME=0



-- 
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 h2-database+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/h2-database/610b15c5-d5fc-4e6b-a8a7-31c1012c1a2an%40googlegroups.com.

Re: [h2] Automatic COMPACT does not seem to work

[Andrei Tokar]

Documentation is outdated. At the time, garbage determination was inexact 
and this was used as additional safety. This is not the case since 1.4.197 
or 1.4.198, premature storage release is not possible anymore. 

On Wednesday, June 22, 2022 at 9:17:39 AM UTC-4 Ulrich wrote:

> The documentation says:
> Using a lower value might be dangerous, unless the file system and hard 
> disk flush the buffers earlier. 
>
> Is it safe to use RETENTION_TIME=0? What are the consequences?
> Do I have to fear that the database file becomes corrupted or that 
> transactions are not consistent?
>
> I would rather try to add RETENTION_TIME=0
>>
>>

-- 
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 h2-database+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/h2-database/fd0b1162-d761-4fbb-953c-eda9a90793d3n%40googlegroups.com.

Re: [h2] Automatic COMPACT does not seem to work

[Andrei Tokar]

I would rather try to add RETENTION_TIME=0

On Tuesday, June 21, 2022 at 8:28:42 AM UTC-4 Ulrich wrote:

> My URL parameters are: 
> LOCK_TIMEOUT=8640;WRITE_DELAY=1;MAX_MEMORY_ROWS=100;MAX_OPERATION_MEMORY=5000;ANALYZE_AUTO=0
>
> I'll check if the compact algorithm works (better) with the default 
> parameters.
>
> andrei...@gmail.com schrieb am Donnerstag, 16. Juni 2022 um 03:31:05 
> UTC+2:
>
>> I wonder how your url looks like, what parameters you are using, 
>> specificaly RETENTION_TIME and WRITE_DELAY ?
>> Are any LOBs involved?
>> With default settings auto compaction should take place in the 
>> background. Whether or not it can keep up with the rate of updates, is a 
>> different story, but the fact that idle database is not compacted at all is 
>> worrysome. 
>> BTW, the fact that file is not shrinking does not nesseccarily means that 
>> there is no compaction going on, like the fact that JVM heap is not 
>> shrinking is not an indication of GC absence.
>> On Tuesday, June 14, 2022 at 5:04:26 AM UTC-4 
>> and...@manticore-projects.com wrote:
>>
>>>
>>>
>>> On Tue, 2022-06-14 at 08:11 +0200, Noel Grandin wrote:
>>>
>>> In general, compacting should work while the db is running, but it's 
>>> fairly conservative
>>>
>>>
>>> Noel,
>>>
>>> not arguing, you know that we do love H2 and are grateful.
>>> Although I never saw any online defragmention doing anything.
>>>
>>> We have 300 MB defragmented content blown up to 20 GByte. The databases 
>>> are idle during the night and most time the day.
>>> Heavy Delete/Write/Querying happens only in the early morning -- but it 
>>> never shrinks, only grows, until "SHUTDOWN DEFRAG".
>>>
>>> Best regards
>>> Andreas
>>>
>>>
>>>

-- 
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 h2-database+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/h2-database/c23ccd12-5e92-4479-844c-bf9a1e7618f0n%40googlegroups.com.

Re: [h2] Automatic COMPACT does not seem to work

[Andrei Tokar]

I wonder how your url looks like, what parameters you are using, 
specificaly RETENTION_TIME and WRITE_DELAY ?
Are any LOBs involved?
With default settings auto compaction should take place in the background. 
Whether or not it can keep up with the rate of updates, is a different 
story, but the fact that idle database is not compacted at all is 
worrysome. 
BTW, the fact that file is not shrinking does not nesseccarily means that 
there is no compaction going on, like the fact that JVM heap is not 
shrinking is not an indication of GC absence.
On Tuesday, June 14, 2022 at 5:04:26 AM UTC-4 and...@manticore-projects.com 
wrote:

>
>
> On Tue, 2022-06-14 at 08:11 +0200, Noel Grandin wrote:
>
> In general, compacting should work while the db is running, but it's 
> fairly conservative
>
>
> Noel,
>
> not arguing, you know that we do love H2 and are grateful.
> Although I never saw any online defragmention doing anything.
>
> We have 300 MB defragmented content blown up to 20 GByte. The databases 
> are idle during the night and most time the day.
> Heavy Delete/Write/Querying happens only in the early morning -- but it 
> never shrinks, only grows, until "SHUTDOWN DEFRAG".
>
> Best regards
> Andreas
>
>
>

-- 
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 h2-database+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/h2-database/5c236e7b-8689-4a09-a2fc-56917e0223f4n%40googlegroups.com.

[h2] Re: Error 50000-210: org.h2.jdbc.JdbcSQLNonTransientException

[Andrei Tokar]

I wonder, if you hit this bug 

It was fixed in a newly released 2.1.212



On Thursday, April 7, 2022 at 7:01:21 PM UTC-4 Jake Dunn wrote:

> I've been trying to resolve this issue when running an integration test 
> against an in-memory H2 database. The query itself seems to work fine when 
> running against an actual Postgres instance in normal development, but I 
> get this error when running against H2. Any thoughts on how to resolve?
>
> ### Error querying database. Cause: 
> org.h2.jdbc.JdbcSQLNonTransientException: General error: 
> "java.lang.NullPointerException"; SQL statement
>
> [5-210]at 
> app//org.h2.message.DbException.getJdbcSQLException(DbException.java:573)   
>  at 
> app//org.h2.message.DbException.getJdbcSQLException(DbException.java:496)   
>  at app//org.h2.message.DbException.get(DbException.java:216)at 
> app//org.h2.message.DbException.convert(DbException.java:414)at 
> app//org.h2.command.Command.executeQuery(Command.java:211)at 
> app//org.h2.jdbc.JdbcPreparedStatement.execute(JdbcPreparedStatement.java:248)
>  
>at 
> app//com.zaxxer.hikari.pool.ProxyPreparedStatement.execute(ProxyPreparedStatement.java:44)
>  
>at 
> app//com.zaxxer.hikari.pool.HikariProxyPreparedStatement.execute(HikariProxyPreparedStatement.java)
>  
>at 
> java...@11.0.12/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
> Method)at 
> java...@11.0.12/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>  
>at 
> java...@11.0.12/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  
>at java...@11.0.12/java.lang.reflect.Method.invoke(Method.java:566)   
>  at 
> app//org.apache.ibatis.logging.jdbc.PreparedStatementLogger.invoke(PreparedStatementLogger.java:59)
>  
>at platform//com.sun.proxy.$Proxy308.execute(Unknown Source)at 
> app//org.apache.ibatis.executor.statement.PreparedStatementHandler.query(PreparedStatementHandler.java:64)
>  
>at 
> app//org.apache.ibatis.executor.statement.RoutingStatementHandler.query(RoutingStatementHandler.java:79)
>  
>at 
> app//org.apache.ibatis.executor.SimpleExecutor.doQuery(SimpleExecutor.java:63)
>  
>at 
> app//org.apache.ibatis.executor.BaseExecutor.queryFromDatabase(BaseExecutor.java:325)
>  
>at 
> app//org.apache.ibatis.executor.BaseExecutor.query(BaseExecutor.java:156)   
>  at 
> app//org.apache.ibatis.executor.CachingExecutor.query(CachingExecutor.java:109)
>  
>at 
> app//org.apache.ibatis.executor.CachingExecutor.query(CachingExecutor.java:89)
>  
>at 
> app//org.apache.ibatis.session.defaults.DefaultSqlSession.selectList(DefaultSqlSession.java:151)
>  
>at 
> app//org.apache.ibatis.session.defaults.DefaultSqlSession.selectList(DefaultSqlSession.java:145)
>  
>at 
> app//org.apache.ibatis.session.defaults.DefaultSqlSession.selectList(DefaultSqlSession.java:140)
>  
>at 
> app//org.apache.ibatis.session.defaults.DefaultSqlSession.selectOne(DefaultSqlSession.java:76)
>  
>at 
> java...@11.0.12/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
> Method)at 
> java...@11.0.12/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>  
>at 
> java...@11.0.12/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  
>at java...@11.0.12/java.lang.reflect.Method.invoke(Method.java:566)   
>  at 
> app//org.mybatis.spring.SqlSessionTemplate$SqlSessionInterceptor.invoke(SqlSessionTemplate.java:427)
>  
>... 150 more Caused by: java.lang.NullPointerExceptionat 
> org.h2.command.query.Query.getParameterValues(Query.java:449)at 
> org.h2.command.query.Query.exists(Query.java:523)at 
> org.h2.expression.condition.ExistsPredicate.getValue(ExistsPredicate.java:25) 
>at 
> org.h2.expression.condition.ConditionAndOrN.getValue(ConditionAndOrN.java:128)
>  
>at 
> org.h2.expression.condition.ConditionAndOr.getValue(ConditionAndOr.java:106) 
>at 
> org.h2.expression.condition.ConditionAndOr.getValue(ConditionAndOr.java:110) 
>at org.h2.expression.Expression.getBooleanValue(Expression.java:332)   
>  at org.h2.table.TableFilter.isOk(TableFilter.java:505)at 
> org.h2.table.TableFilter.next(TableFilter.java:451)at 
> org.h2.command.query.Select$LazyResultQueryFlat.fetchNextRow(Select.java:1825)
>  
>at org.h2.result.LazyResult.hasNext(LazyResult.java:78)at 
> org.h2.result.FetchedResult.next(FetchedResult.java:34)at 
> org.h2.command.query.Select.queryFlat(Select.java:728)at 
> org.h2.command.query.Select.queryWithoutCache(Select.java:833)at 
> org.h2.command.query.Query.queryWithoutCacheLazyCheck(Query.java:197)at 
> org.h2.command.query.Query.query(Query.java:494)at 
> org.h2.command.query.Query.query(Query.java:457)at 
> org.h2.index.ViewIndex.find(ViewIndex.java:270)at 
> or

[h2] H2 Database Engine: New version released

[Andrei Tokar]

Hello,

A new version 2.1.212 of H2 is available at http://www.h2database.com
(you may have to click 'Refresh').

It will be available in Maven repository shortly.

For details, see the 'Change Log' at
http://www.h2database.com/html/changelog.html

P.S. If you reply to this message please use a different subject.

Have fun,
Andrei Tokar

-- 
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 h2-database+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/h2-database/ef15303d1bef871b851f2553511a21bd8f978302.camel%40gmail.com.

[h2] Re: 2.0.206 Memory leak when AUTO_COMPACT_FILL_RATE=0 and REUSE_SPACE=false

[Andrei Tokar]

This is exactly behaviour, I would expect, if you explicitely disable any 
space reuse. I wonder what was the size of the database file and how it's 
growth correlates with heap size increase?

On Sunday, January 16, 2022 at 12:55:16 PM UTC-5 lowch...@gmail.com wrote:

> Hi,
>
> I am running H2 db with AUTO_COMPACT_FILL_RATE=0 and REUSE_SPACE=false in 
> a long running process that will keep inserting some records to multiple 
> tables and the heap memory keep increasing. I manually invoke GC and dump 
> the heap and notice that chunksToC within MVStore is using a lot of 
> memory. 
>
> Regards,
> Chin Wei
>

-- 
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 h2-database+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/h2-database/bfd4d1cc-d653-41c7-bb8e-672774518a3dn%40googlegroups.com.

[h2] H2 Database Engine: New version 2.1.210 released

[Andrei Tokar]

Hello,

A new version 2.1.210 of H2 is available at http://www.h2database.com
(you may have to click 'Refresh').

For details, see the 'Change Log' at
http://www.h2database.com/html/changelog.html


P.S. If you reply to this message please use a different subject.

Have fun,
Andrei Tokar

-- 
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 h2-database+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/h2-database/2edcbd33c3e21298c7c1a584bdb42521fea1379c.camel%40gmail.com.

[h2] Re: The Parser doubles params for stored procedures in v.2.0.206

[Andrei Tokar]

This issue and possible workarounds are described  here 
 and addressed by 
this  PR .
Fix will be included in the nex H2 release.
On Wednesday, January 12, 2022 at 2:05:17 PM UTC-5 Artem Bilan wrote:

> Hi there!
>
> Having issues with stored procedures in new H2 version.
> This is the code to reproduce:
>
> import java.math.BigInteger;
> import java.sql.CallableStatement;
> import java.sql.Connection;
> import java.sql.DriverManager;
> import java.sql.ResultSet;
> import java.sql.SQLException;
> import java.sql.Statement;
> import java.sql.Types;
>
> import org.h2.tools.SimpleResultSet;
> import org.junit.Test;
>
> public class H2StoredProcTests {
>
>
> @Test
> public void h2ParserProblem() throws SQLException {
> try (Connection connection =
> DriverManager.getConnection(
> "jdbc:h2:mem:test;DB_CLOSE_DELAY=-1;DB_CLOSE_ON_EXIT=true", "sa", "")) {
> try (Statement statement = connection.createStatement()) {
> statement.execute("CREATE ALIAS GET_PRIME_NUMBERS FOR \"
> H2StoredProcTests.getPrimes\"");
> }
> try (CallableStatement callableStatement = connection.prepareCall("{ CALL 
> GET_PRIME_NUMBERS(?, ?) }")) {
> callableStatement.setInt(1, 0);
> callableStatement.setInt(2, 10);
> callableStatement.execute();
> }
> }
> }
>
> public static ResultSet getPrimes(int beginRange, int endRange) {
> SimpleResultSet rs = new SimpleResultSet();
> rs.addColumn("PRIME", Types.INTEGER, 10, 0);
> for (int i = beginRange; i <= endRange; i++) {
> if (new BigInteger(String.valueOf(i)).isProbablePrime(100)) {
> rs.addRow(i);
> }
> }
>
> return rs;
> }
>
> }
>
> Works well in the previous 1.4.200 version.
>
> Looks like something has been broken in the org.h2.command.Parser and now 
> it parsers params twice:
>
> [image: Params_screenshot.PNG]
>
> The failure in the end looks like this:
>
> org.h2.jdbc.JdbcSQLDataException:
> Parameter "#3" is not set; SQL statement:
>   CALL GET_PRIME_NUMBERS(?, ?)   [90012-206]
>
> at 
> org.h2.message.DbException.getJdbcSQLException(DbException.java:665)
> at 
> org.h2.message.DbException.getJdbcSQLException(DbException.java:496)
> at org.h2.message.DbException.get(DbException.java:227)
> at org.h2.message.DbException.get(DbException.java:203)
> at org.h2.expression.Parameter.checkSet(Parameter.java:75)
> at org.h2.command.Prepared.checkParameters(Prepared.java:181)
> at org.h2.command.CommandContainer.query(CommandContainer.java:254)
> at org.h2.command.Command.executeQuery(Command.java:190)
> at 
> org.h2.jdbc.JdbcPreparedStatement.execute(JdbcPreparedStatement.java:248)
> at H2StoredProcTests.h2ParserProblem(H2StoredProcTests.java:26)
>
> Thank you!
>
> Regards,
> Artem Bilan
>
>

-- 
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 h2-database+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/h2-database/298ecb40-bb03-4346-a119-2cb6fa7eed48n%40googlegroups.com.

[h2] H2 Database Engine: New version released

[Andrei Tokar]

Hello,

A new version 2.0.206 of H2 is available at http://www.h2database.com
(you may have to click 'Refresh').

It contains a patch for H2 console security issue:
https://github.com/h2database/h2database/security/advisories/GHSA-h376-j262-vhq6

For details, see the 'Change Log' at
http://www.h2database.com/html/changelog.html


P.S. If you reply to this message please use a different subject.

Have fun,
Andrei Tokar


-- 
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 h2-database+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/h2-database/0b147f7ba3dc30d2863d579019cf955ba7ad6bca.camel%40gmail.com.

[h2] Re: Create table error in 2.x, unsure how to interpret: expected "IDENTITY, BIGSERIAL, SERIAL, data type"

[Andrei Tokar]

Hi Vladimir,

Please take a look at your error message again:
... amr ARRAY*[*]*, creation_ts ...
Marker [*] shows where parser had choked, and something of sort "IDENTITY, 
BIGSERIAL, SERIAL, data type" is expected instead.
At this point, it should be pretty clear that ARRAY has to be typed, and 
that is indeed a new requirement in 2.x, in line with SQL standard.
You can consult documentation for exact syntax: 
https://h2database.com/html/datatypes.html#array_type
And yes, syntax diagrams are supposed to be up to date.

-- 
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 h2-database+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/h2-database/fbc0af26-5d0b-41f2-9681-5df89ba0e514n%40googlegroups.com.

[h2] Re: H2 Database Engine: New version released

[Andrei Tokar]

"KEY" (as well as "VALUE") is a keyword now, and if used as identifier has 
to be quoted.

https://h2database.com/html/advanced.html#keywords

On Thursday, December 23, 2021 at 8:26:19 AM UTC-5 garydg...@gmail.com 
wrote:

> To be more precise, we are calling Connection#prepareStatement(String) 
> with:
>
> "CREATE TABLE TEST_DATA (KEY VARCHAR(100), ID BIGINT, VALUE DOUBLE 
> PRECISION, INFO TEXT, TS TIMESTAMP)"
>
> Gary
>
> On Thursday, December 23, 2021 at 8:23:58 AM UTC-5 Gary Gregory wrote:
>
>> Hello from Apache Commons DBCP: There appears to be some breakage we 
>> notice when updating from 200 to 204.
>>
>> The full build log for the PR "Bump h2 from 1.4.200 to 2.0.204 Java CI 
>> #560" is here: 
>> https://github.com/apache/commons-dbcp/runs/4614345120?check_suite_focus=true
>>
>> For example:
>>
>> org.h2.jdbc.JdbcSQLSyntaxErrorException: 
>> 129 
>> <https://github.com/apache/commons-dbcp/runs/4614345120?check_suite_focus=true#step:5:129>
>>  Syntax error in SQL statement "CREATE TABLE TEST_DATA (KEY[*] 
>> VARCHAR(100), ID BIGINT, VALUE DOUBLE PRECISION, INFO TEXT, TS TIMESTAMP)"; 
>> expected "identifier"; SQL statement: 
>> 130 
>> <https://github.com/apache/commons-dbcp/runs/4614345120?check_suite_focus=true#step:5:130>
>>  CREATE TABLE TEST_DATA (KEY VARCHAR(100), ID BIGINT, VALUE DOUBLE 
>> PRECISION, INFO TEXT, TS TIMESTAMP) [42001-204] 
>> 131 
>> <https://github.com/apache/commons-dbcp/runs/4614345120?check_suite_focus=true#step:5:131>
>>  
>> at 
>> org.apache.commons.dbcp2.managed.TestConnectionWithNarayana.setUp(TestConnectionWithNarayana.java:91)
>>
>> Any thoughts?
>>
>> Gary
>>
>> On Wednesday, December 22, 2021 at 1:56:44 PM UTC-5 andrei...@gmail.com 
>> wrote:
>>
>>> Hello, 
>>>
>>> A new version 2.0.204 of H2 is available at http://www.h2database.com 
>>> (you may have to click 'Refresh'). 
>>>
>>> For details, see the 'Change Log' at 
>>> http://www.h2database.com/html/changelog.html 
>>>
>>>
>>> P.S. If you reply to this message please use a different subject. 
>>>
>>> Have fun, 
>>> Andrei Tokar 
>>>
>>

-- 
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 h2-database+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/h2-database/6ffeec91-8d63-4ec2-9df7-70052e0670e3n%40googlegroups.com.

[h2] H2 Database Engine: New version released

[Andrei Tokar]

Hello,

A new version 2.0.204 of H2 is available at http://www.h2database.com
(you may have to click 'Refresh').

For details, see the 'Change Log' at
http://www.h2database.com/html/changelog.html


P.S. If you reply to this message please use a different subject.

Have fun,
Andrei Tokar

-- 
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 h2-database+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/h2-database/cfdfbb7ed1f1f3dddf6c1ed0091b1bd6bd74a561.camel%40gmail.com.

[h2] Re: H2 2.0.202 table metadata tabletype is "BASE TABLE" instead "TABLE"

[Andrei Tokar]

Please see comments on https://github.com/h2database/h2database/issues/3213

On Tuesday, November 30, 2021 at 1:46:58 PM UTC-5 raimund...@googlemail.com 
wrote:

> Hello,
>
> congratulations and many thanks for the new H2 release.
>
> I started to migrate some applications and found the following changed 
> behaviour:
>
>- CREATE TABLE TEST_1 (MY_COL CHARACTER VARYING(10))
>- Get the table type per JDBC:
>- rs = connection.getMetaData().getTables(...); rs.next(); 
>rs.getString("TABLE_TYPE");
>- H2 version 1.x delivers "TABLE", but 2.x returns "BASE TABLE".
>
> I'm not sure if it is really a bug, but it is at least an unexpected 
> behaviour not seen with other JDBC drivers. Although the table is actually 
> a "base table" regarding the ANSI/ISO standard, there exists no 
> standardized keywords like "BASE" (only "GLOBAL|LOCAL TEMPORARY" are 
> allowed as table scope).
>
> SSCC example: https://pastebin.com/Tg0zc2C3
>
> Best regards
>

-- 
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 h2-database+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/h2-database/0d086bc5-c8d1-41b3-8882-9138ba66ba08n%40googlegroups.com.

[h2] H2 Database Engine: New version released

[Andrei Tokar]

Hello,

A new version of H2 is available at http://www.h2database.com
(you may have to click 'Refresh').

For details, see the 'Change Log' at
http://www.h2database.com/html/changelog.html


P.S. If you reply to this message please use a different subject.

Have fun,
Thomas




-- 
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 h2-database+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/h2-database/d08e26df2e2515c35fd7026e46a63bf01221f777.camel%40gmail.com.

[h2] Re: MVMAP descending order

[Andrei Tokar]

MVMap is always constructed in ascending order, although it's possible to 
re-define what "ascending" means.
In the upcoming release, or if you build library yourself, there is a 
possibility to iterate MVMap in reverse order.
On Wednesday, November 24, 2021 at 11:06:01 AM UTC-5 Tiago wrote:

> Is there a way to have the keys in MVMap sorted in descending order? Or 
> iterate the map starting at the end?
>
> Thx

-- 
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 h2-database+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/h2-database/c25acbb6-7f4a-44c3-a75c-ddc218a89a1en%40googlegroups.com.

Re: [h2] Re: unique index versus primary key

[Andrei Tokar]

Please note that it is complaining about missing constraint. Indeed, you 
create a unique index, but not a unique constraint, which is required for 
referential integrity constraint.
If instead you define table as 
create table ftypes(ID IDENTITY primary key , types VARCHAR UNIQUE );
it will generate a constraint (and index shouldl be created automatically), 
and everything just works.
On Tuesday, November 23, 2021 at 9:02:41 AM UTC-5 yambo wrote:

> Hi,
>
> sorry wrong cut/paste
>
> Still the same error : 
> Constraint "PRIMARY KEY | UNIQUE (TYPES)" not found; SQL statement:
> CREATE  TABLE FCOUNTS( ID IDENTITY primary key , NR VARCHAR, 
> NAME VARCHAR, TYPES VARCHAR, TAG VARCHAR, Foreign key(types) 
> references ftypes(types), Foreign key(tag) references ftags(tag) ) 
> [90057-200]
>
>
>
> create  table ftypes(
> ID IDENTITY primary key ,
> types VARCHAR
> );
>
> create unique index ftype_idx on ftypes(types);
>
> create  table ftags(
> ID IDENTITY primary key ,
> tag VARCHAR
> );
> create unique index ftag_idx on ftags(tag);
>
>
>
> CREATE  TABLE FCOUNTS(
> ID IDENTITY primary key ,
> NR VARCHAR,
> NAME VARCHAR,
> TYPES VARCHAR,
> TAG VARCHAR,
> Foreign key(types) references ftypes(types),
> Foreign key(tag) references ftags(tag)
> );
>
>
> On 11/23/21 14:51, Andrei Tokar wrote:
>
> I wonder if that's because of *create unique index ftag_idx on 
> fintags(tag); *
> contains invalid table name?
>
> On Sunday, November 21, 2021 at 4:07:10 AM UTC-5 yambo wrote:
>
>> Hi, 
>>
>> The following works in 1.4.200, but gives the following error in 
>> 1.4.201   : 
>> Any ideas ? 
>>
>> Kind regards 
>>
>> Willy 
>>
>>  Constraint "PRIMARY KEY | UNIQUE (TYPES)" not found; SQL statement: 
>> CREATE  TABLE FCOUNTS( ID IDENTITY primary key , NR VARCHAR, 
>> NAME VARCHAR, TYPES VARCHAR, TAG VARCHAR, Foreign key(types) 
>> references ftypes(types), Foreign key(tag) references ftags(tag) ) 
>>
>> Code : 
>>
>> create  table ftypes( 
>> ID IDENTITY primary key , 
>> types VARCHAR 
>> ); 
>>
>> create unique index ftype_idx on ftypes(types); 
>>
>> create  table ftags( 
>> ID IDENTITY primary key , 
>> tag VARCHAR 
>> ); 
>> create unique index ftag_idx on fintags(tag); 
>>
>>
>> CREATE  TABLE FCOUNTS( 
>> ID IDENTITY primary key , 
>> NR VARCHAR, 
>> NAME VARCHAR, 
>> TYPES VARCHAR, 
>> TAG VARCHAR, 
>> Foreign key(types) references ftypes(types), 
>> Foreign key(tag) references ftags(tag) 
>> ); 
>>
> -- 
> 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 h2-database...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/h2-database/3d57f368-0b7a-4960-81ec-4cdc82ab4b3an%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/h2-database/3d57f368-0b7a-4960-81ec-4cdc82ab4b3an%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
>
>

-- 
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 h2-database+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/h2-database/d130a84a-5e58-480c-9faa-c25000d6e089n%40googlegroups.com.

[h2] Re: unique index versus primary key

[Andrei Tokar]

I wonder if that's because of *create unique index ftag_idx on 
fintags(tag); *
contains invalid table name?

On Sunday, November 21, 2021 at 4:07:10 AM UTC-5 yambo wrote:

> Hi,
>
> The following works in 1.4.200, but gives the following error in 
> 1.4.201   :
> Any ideas ?
>
> Kind regards
>
> Willy
>
>  Constraint "PRIMARY KEY | UNIQUE (TYPES)" not found; SQL statement:
> CREATE  TABLE FCOUNTS( ID IDENTITY primary key , NR VARCHAR, 
> NAME VARCHAR, TYPES VARCHAR, TAG VARCHAR, Foreign key(types) 
> references ftypes(types), Foreign key(tag) references ftags(tag) )
>
> Code :
>
> create  table ftypes(
> ID IDENTITY primary key ,
> types VARCHAR
> );
>
> create unique index ftype_idx on ftypes(types);
>
> create  table ftags(
> ID IDENTITY primary key ,
> tag VARCHAR
> );
> create unique index ftag_idx on fintags(tag);
>
>
> CREATE  TABLE FCOUNTS(
> ID IDENTITY primary key ,
> NR VARCHAR,
> NAME VARCHAR,
> TYPES VARCHAR,
> TAG VARCHAR,
> Foreign key(types) references ftypes(types),
> Foreign key(tag) references ftags(tag)
> );
>

-- 
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 h2-database+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/h2-database/3d57f368-0b7a-4960-81ec-4cdc82ab4b3an%40googlegroups.com.

[h2] Re: compactRewriteFully safety with DB writes

[Andrei Tokar]

Hi Matt,

After reading your last message, I still fail to understand what exactly 
"no longer works" with 1.4.200?
If your concern is a heap usage increase, I would say it should never be a 
problem on it's own, and in this case it is kind of expected, because cache 
now may keep weak references for items that were just dropped in previous 
version.
You also mention attempt to run in-memory configuration, does it fail with 
1.4.200?

On Sunday, July 25, 2021 at 2:41:45 AM UTC-4 matt...@gmail.com wrote:

> Sorry to keep replying to myself, but another question.
>
> After trialling the latest H2 (1.4.200) with our existing data, I saw heap 
> usage shoot up from 150-200MB where it hovers with 1.4.147 to 840M and 
> rising after a fairly short run time. 
>
> Now, I expect this is totally caused by my set up since (a) our 
> DataType.getMemory () simply returns 1024, and our MVStore cache size is 
> set to 32000 (~32GB). I chose this due to the above issues with object size 
> estimation so that data would effectively never leave the cache, and we 
> manage long-term this by flushing the cache every 24 hours.
>
> Since the dataset in this case fits in a 35MB .mv file (it is compressed 
> with LZW though), the all-in-memory idea seemed reasonable, and indeed ran 
> stably with 1.4.197. 
>
> I can see from the source code for Page and MVMap that a lot of work has 
> gone into this area, but after some time looking at it I'm still not sure 
> how to proceed, other than playing with other numbers for getMemory () 
> and/or cache size.
>
> Do you have any ideas why my hacky solution no longer works and/or 
> suggestions on how I might approach making it work with 1.4.200?
>
> Cheers,
>
> Matt.
>
> On Monday, July 19, 2021 at 11:24:30 AM UTC+9:30 Matthew Phillips wrote:
>
>> Hi Andrei,
>>
>> thanks again. We have a use-case that's very high on writes/deletes, and 
>> the DB was apparently getting very fragmented. Using regular compact() with 
>> 80 fill rate has halved the size, and we've done away with the nightly "big 
>> compact" task. So for this use case it's working very well so far.
>>
>> The need for a cache flush is due to the fact that we store many versions 
>> of the same data, most of them as small diffs against a previous version. 
>> We reconstitute these versions into Clojure persistent maps, which means 
>> there's a very high level of structural sharing between objects. So when 
>> adding two maps A & B to the cache, the used memory for those maps is 
>> almost certainly nothing like getMemory(A) + getMemory(B) due to (probable) 
>> structural sharing between them. 
>>
>> We did try some heuristic workarounds, but were always off by so much 
>> that performance suffered badly (either flushing the cache when we didn't 
>> need to, or writing too often). So, we use an effectively infinite cache, 
>> flush overnight and let it re-fill. Not ideal, but don't have a better 
>> solution right now.
>>
>> Cheers,
>>
>> Matt.
>> On Sunday, July 18, 2021 at 11:49:43 PM UTC+9:30 andrei...@gmail.com 
>> wrote:
>>
>>> Hi Matt,
>>> IMHO, the best way to compact will be off-line one - 
>>> MVStoreTool.compact(), and it can take only seconds (your mileage may very, 
>>> of course).
>>> If you can not afford 1 min off-line interruption, then you can try just 
>>> to let it run and do it's own maintenance in the background (asuming 
>>> autoCommitDelay > 0).
>>> If I only knew some "best/better" way for on-line compaction, it would 
>>> probably be there already, as a background maintenance procedure.
>>> I expect that the existing one will fit the bill, unless you update rate 
>>> is quite high.
>>> BTW, flushing the cache looks like a futile exercise, indeed.
>>>
>>> On Thursday, July 15, 2021 at 7:36:05 PM UTC-4 matt...@gmail.com wrote:
>>>
 Hello Andrei,

 thanks very much for your reply. 

 Yes, I'm aware I'm on an old version: if it's not broken, don't fix it 
 ;) Version 1.4.197 has been rock-solid for us for years, and I'm always 
 loathe to change things for no reason. But you have given me a good 
 reason, 
 so I'll give the latest MVStore a try.

 Can you recommend the best way to 'manually' compact the database in 
 the latest release?

 And just to be sure: could there be any data-loss issues from flushing 
 the cache?

 Cheers,

 Matt.

 On Friday, July 16, 2021 at 4:45:12 AM UTC+9:30 andrei...@gmail.com 
 wrote:

> Hi Matt,
>
> If you are experiencing a problem, which looks and smells like a 
> cuncurrency issue, then there is definitely a good reason to suspect a 
> concurrency issue. 8-)
> The real question here is: if you care enough about those problems, 
> why are you still on version 1.4.197. MVStore's concurrency / 
> synchronization was totally re-designed since then (and we are talking 
> years here), for example you will not even find 
> MVStore.compactRewriteFu

[h2] Re: compactRewriteFully safety with DB writes

[Andrei Tokar]

Hi Matt,
IMHO, the best way to compact will be off-line one - MVStoreTool.compact(), 
and it can take only seconds (your mileage may very, of course).
If you can not afford 1 min off-line interruption, then you can try just to 
let it run and do it's own maintenance in the background (asuming 
autoCommitDelay > 0).
If I only knew some "best/better" way for on-line compaction, it would 
probably be there already, as a background maintenance procedure.
I expect that the existing one will fit the bill, unless you update rate is 
quite high.
BTW, flushing the cache looks like a futile exercise, indeed.

On Thursday, July 15, 2021 at 7:36:05 PM UTC-4 matt...@gmail.com wrote:

> Hello Andrei,
>
> thanks very much for your reply. 
>
> Yes, I'm aware I'm on an old version: if it's not broken, don't fix it ;) 
> Version 1.4.197 has been rock-solid for us for years, and I'm always loathe 
> to change things for no reason. But you have given me a good reason, so 
> I'll give the latest MVStore a try.
>
> Can you recommend the best way to 'manually' compact the database in the 
> latest release?
>
> And just to be sure: could there be any data-loss issues from flushing the 
> cache?
>
> Cheers,
>
> Matt.
>
> On Friday, July 16, 2021 at 4:45:12 AM UTC+9:30 andrei...@gmail.com wrote:
>
>> Hi Matt,
>>
>> If you are experiencing a problem, which looks and smells like a 
>> cuncurrency issue, then there is definitely a good reason to suspect a 
>> concurrency issue. 8-)
>> The real question here is: if you care enough about those problems, why 
>> are you still on version 1.4.197. MVStore's concurrency / synchronization 
>> was totally re-designed since then (and we are talking years here), for 
>> example you will not even find MVStore.compactRewriteFully() method 
>> anymore, but instead it might just do all that space management, so you 
>> won't need that background operation at all.
>> In any case, I would not expect that someone will look at 1.4.197 issues 
>> at this point. On the other hand, if you will find similar problem with 
>> current trunk version, and will be able to reproduce it, I will be more 
>> than happy to work on it.
>>
>> Cheers,
>> Andrei.
>>
>> On Thursday, July 15, 2021 at 3:39:40 AM UTC-4 matt...@gmail.com wrote:
>>
>>> Hello,
>>>
>>> I'm trying to track down a perplexing problem when using an MVStore, 
>>> where it appears that a write using MVMap.put() is being dropped (H2 
>>> 1.4.197). It's only happened twice, but both of those times have been after 
>>> a series of cache flushes, and where the .put() is done *concurrently* with 
>>> a long-running call to compactRewriteFully() (which takes around 90s for 
>>> this DB). We're not using rollback, or transactions or anything fancy, just 
>>> raw put(), get(), commit().
>>>
>>> My question: is there any reason to suspect that the cache flushes or, I 
>>> think more likely, the concurrent compactRewriteFully() might somehow be 
>>> causing the write to be dropped?
>>>
>>> If so, I'm open to compacting the DB in some other way, but 
>>> compactRewriteFully() has been the most reliable at keeping the DB size 
>>> stable, despite its overhead (it's currently being run from a background 
>>> thread that runs once a day in the wee hours).
>>>
>>> Cheers,
>>>
>>> Matt.
>>>
>>

-- 
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 h2-database+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/h2-database/1544427a-3515-4311-9c15-4be75f15305en%40googlegroups.com.

[h2] Re: compactRewriteFully safety with DB writes

[Andrei Tokar]

Hi Matt,

If you are experiencing a problem, which looks and smells like a 
cuncurrency issue, then there is definitely a good reason to suspect a 
concurrency issue. 8-)
The real question here is: if you care enough about those problems, why are 
you still on version 1.4.197. MVStore's concurrency / synchronization was 
totally re-designed since then (and we are talking years here), for example 
you will not even find MVStore.compactRewriteFully() method anymore, but 
instead it might just do all that space management, so you won't need that 
background operation at all.
In any case, I would not expect that someone will look at 1.4.197 issues at 
this point. On the other hand, if you will find similar problem with 
current trunk version, and will be able to reproduce it, I will be more 
than happy to work on it.

Cheers,
Andrei.

On Thursday, July 15, 2021 at 3:39:40 AM UTC-4 matt...@gmail.com wrote:

> Hello,
>
> I'm trying to track down a perplexing problem when using an MVStore, where 
> it appears that a write using MVMap.put() is being dropped (H2 1.4.197). 
> It's only happened twice, but both of those times have been after a series 
> of cache flushes, and where the .put() is done *concurrently* with a 
> long-running call to compactRewriteFully() (which takes around 90s for this 
> DB). We're not using rollback, or transactions or anything fancy, just raw 
> put(), get(), commit().
>
> My question: is there any reason to suspect that the cache flushes or, I 
> think more likely, the concurrent compactRewriteFully() might somehow be 
> causing the write to be dropped?
>
> If so, I'm open to compacting the DB in some other way, but 
> compactRewriteFully() has been the most reliable at keeping the DB size 
> stable, despite its overhead (it's currently being run from a background 
> thread that runs once a day in the wee hours).
>
> Cheers,
>
> Matt.
>

-- 
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 h2-database+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/h2-database/792987e2-3f57-4a04-a3d5-b1e512114f0fn%40googlegroups.com.

[h2] Re: MVStore vs H2 performance

[Andrei Tokar]

First of all it is absolutely not aples-to-apples, and the fact of using 
BLOB sql type just makes the water more muddy. Now, You have to realize 
that database commit, won't write it (do mvstore commit), unless your 
WRITE_DELAY=0, 
and H2 will slow down.
If you want to somewhat mimic H2, dont issue  MVStore.commit(), because it 
has nothing to do with db commit.


On Wednesday, May 19, 2021 at 10:45:19 AM UTC-4 wburzyns wrote:

>
> Hi,
>
> I need some insight regarding the performance of MVStore persisted 
> transactional maps (used in a single-thread environment).
> I did some benchmarks with MVStore (using it the same way it's used in the 
> TestTransactionStore.java) and - to my great surprise - the performance is 
> worse than performance of H2 used in the same scenario (i.e. as a key-value 
> store).
>
> In MVStore I'm operating on a map declared as TransactionMap byte[]>. In H2 I have DATA_TABLE(ID BIGINT NOT NULL PRIMARY KEY, DATA 
> BLOB). While inserts are 30-40% faster in case of MVStore, the commit 
> operation (i.e. Transaction.commit() vs SQL "COMMIT") is ~9x slower in case 
> of MVStore. 
>
> 1) I changed the way my MVStore is built to the same settings H2 is using, 
> but it didn't help:
>
> MVStore.Builder().fileName(mvStorePath).compress().autoCommitDisabled().autoCompactFillRate(90).pageSplitSize(65536).open()
>
> 2) I've walked with debugger through H2 row insertion and noticed that H2 
> is opening maps not via Transaction.openMap() but via 
> TransactionMap.getInstance(txn), however changing the MVStore benchmark 
> code accordingly did not improve my results at all.
>
> I don't understand how it is possible that H2 that uses MVStore as its 
> storage engine and adds a lot of other stuff on top of it (SQL) can be 
> faster than raw MVStore. Am I doing something wrong? If I don't, is there a 
> way I can mimic H2's way of using MVStore to improve commit performance?
>
>
> Thanks,
> wburzyns

-- 
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 h2-database+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/h2-database/5115f64e-ec0d-4c5f-98a3-9200fd1900f8n%40googlegroups.com.

[h2] Re: Locking in Pagestore Engine Indices

[Andrei Tokar]

Please note, that PageStore is not in active development any more. H2 
currently uses MVStore as it's default storage engine.

On Sunday, February 21, 2021 at 11:35:37 AM UTC-5 thamin...@cse.mrt.ac.lk 
wrote:

> Hi,
>
> We are exploring the H2 database implementation details regarding the
> pagestore engine. We are interested to know the below details about the
> pagestore indexing.
>
> 1. How does the pagestore Btree locking happens?
>
> 2. We observed that you are using a synchronized block in the 
> pagestore/db/PageStoreBtreeIndex.java
> <
> https://github.com/h2database/h2database/blob/888e2284ffc5a76ebc1cf7346144e815b9c44813/h2/src/main/org/h2/pagestore/db/PageBtreeIndex.java#L350>
>  
>
> file. As mentioned in the docs, if you're using table-level locking, what 
> is
> the purpose of this block?
>
> 3. How does the locking happen for Hash and AVL Tree indices? (We observed
> that none of the blocks were synchronized in those two codes)
>
> Thank you
>
>
>
> --
> Sent from: http://h2-database.66688.n3.nabble.com/
>

-- 
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 h2-database+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/h2-database/c9191b0e-ca07-45ce-8994-511b8ac40d66n%40googlegroups.com.

[h2] Re: Concurent B+tree indexing in H2 Database

[Andrei Tokar]

Hi JS,

First of all, there are two storage implementations co-exist in H2, old 
"PageStore" and a newer one called "MVStore". 
I won't speak for PageStore, since it's not in active development anymore, 
but it's concurrency is implemented as lock for the whole tree.
BTW, both storages use B-tree, and not B+ tree.
MVStore, on the other hand, as it is multi-version storage, does not have 
any locking at all, because it's modifications are copy-on-write, with 
non-blocking atomic updates of the tree root reference. Readers always 
proceed without any locks and see whatever tree version was at the time of 
tree root reference reading. Writers use optistic concurrency control and 
retry their operation if concurrent modification is encountered. Only in 
case of extremely contentious operations, when many update attempts would 
fail, writers will resort to a tree-wise update lock instead.
I hope that at this point you do realize already, that yes, "H2 database is 
concurrent".

On Sunday, February 21, 2021 at 11:35:10 AM UTC-5 js wrote:

> Hi,
> I want to improve the locking mechanism in the B+ tree in the H2 database. 
> But I didn't see any locking mechanism related to B+ Tree nodes in the H2 
> database. Hence I want to know whether the B+ tree in the H2 database is 
> concurrent or not.
>
> Thank you,
> JS
>

-- 
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 h2-database+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/h2-database/470e09f8-b7a9-419f-b4a7-ff8e6dd63bf9n%40googlegroups.com.

Re: [h2] Re: Time To First Row on large ResultSet

[Andrei Tokar]

Hi Val,
The reason for the execution time difference that you see between full scan 
of the original table (LAZY_QUERY_EXECUTION, 20min) vs. scan of the 
intermediate temp table (6 min), could be related to the fact that database 
may be very sparsely populated (as a result of inserts/updates during it's 
construction), whereas temp table supposedly is pretty dense (built in 
special "append" mode). I wonder, what is the size of that temp file? It 
would show you amount of real data you have, and I suspect it's somewhat 
smaller than 40+GB in you database. You can try do "SHUTDOWN COMPACT" 
(assuming you are using v.1.4.200 and have a backup), and most likely size 
of the db and it's scan time will go down after that (to ~6 min for lazy 
exec?), unless I am missing something and lazy execution has some 
significant overhead.

On Wednesday, November 11, 2020 at 12:14:38 AM UTC-5 val wrote:

> If I understand what Evgenij is saying, that temp file is how the 
> h2-db-engine behaves, afterall, it is NOT the result set, but is a internal 
> temporary H2 structure.
>
> I still dont understand why ResultSet iteration so much faster from this 
> temporary structure, compared to directly from the database using 
> LAZY_QUERY_EXECUTION. We are talking 6 minutes vs 20 minutes. I can 
> understand if there were other requirements like sorting, filtering or 
> joining; then I could see how that would require a temporary structure. But 
> in this case the query is a  basic SELECT * FROM TABLE, why would the 
> LAZY_QUERY_EXECUTION approach not be able to iterate all the rows in the 
> same 6 minutes as with the temporary structure.
>
> Perhaps the rows in the database are stored differently in the db than in 
> the temporary structure that makes them easier/cheaper to iterate?
>
> Separately; should we use LAZY_QUERY_EXECUTION=TRUE by default? If it can 
> already detect if it needs to use a temporary structure or not; is there 
> any drawback? Its a bit of an odd programming pattern to have to setup 
> different connection urls depending on what you are trying to select. 
> On Tuesday, November 10, 2020 at 8:13:24 PM UTC-5 Evgenij Ryazanov wrote:
>
>> Hello.
>>
>> There is nothing to do with temporary results in H2. If you have large 
>> queries and they may return parts of results early, use 
>> `LAZY_QUERY_EXECUTION=TRUE`. If some query doesn't support lazy execution, 
>> there is nothing to do with it in H2 itself. With 
>> `LAZY_QUERY_EXECUTION=TRUE` H2 uses LocalResult if and only if rows need a 
>> post-processing, such as sorting, distinct filtration, or OFFSET / FETCH 
>> filtration and these operations can't be performed early, for example, 
>> because there are no compatible indexes or some previous step needs a 
>> complete set of rows. In all these cases rows passed to LocalResult are not 
>> the same rows as will be returned by ResultSet.
>>
>

-- 
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 h2-database+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/h2-database/99dbd6af-7705-4f25-a44d-6d45e11f86b2n%40googlegroups.com.

Re: [h2] MvStore cache leak

[Andrei Tokar]

I guess, you next step could be to reduce configured cache size to some 
reasonable number.
What makes you believe that you actually need such huge cache?
If you have configured MVStore cache size to be 4Gb, how can you expect 
usedMemory field (which is java int) to always stay positive?

On Friday, October 23, 2020 at 2:15:44 PM UTC-4 Noel Grandin wrote:

> That looks like an integer overflow somewhere. 
>
> I would tweak the source code in the places that modify that field, to 
> dump stack traces, and work backwards.
>

-- 
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 h2-database+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/h2-database/eaf4273c-c2d7-41dc-b77b-5e76ff9c2aafn%40googlegroups.com.

[h2] Re: database(dbms) replicate sort order in ascending and descending from all data strcture for fast query?

[Andrei Tokar]

We may even implement that optimization mentioned by Evgenij, regardless of 
the original index order (add case of exact opposite order, to be precise), 
because both direct and reverse iterators are available now on the 
underlying B-Tree (MVMap). Existence of NULL values in the order may 
complicate things somewhat thought.

-- 
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 h2-database+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/h2-database/29bd6967-5b45-4674-af94-af3f50504ff7o%40googlegroups.com.

[h2] Re: How to decrease database size?

[Andrei Tokar]

Setting RETENTION_TIME to a smaller value, or even zero, will help. Also 
keeping database up and let it do background housekeeping after massive 
changes (or do changes at slower pace) will help too, but most effective 
way to reduce file size to a bare minimum, as you already know is SHUTDOWN 
COMPACT command.

On Thursday, July 30, 2020 at 8:38:02 AM UTC-4, Jack Green wrote:
>
> I've noticed that my H2 database seems to grow and grow.
>
> I've got a database, which includes a table with 1.5 million rows.
> This database is currently 6GB.
>
> If I run a query to add a new column to the table, and modify an existing 
> column, and then disconnect - it grows to 22GB.
>
> If I then reconnect and run a SHUTDOWN COMPACT, the shrinks to 0.7GB.
>
> Clearly theres gigabytes of redundant data being stored, so my question is 
> how can I reduce the peak size of the database?
>
> I've assumed it's transaction logs / checkpoints thats causing this, but I 
> don't know for sure.
>
> Are there any parameters I can tweak (e.g. the RETENTION_TIME) to improve 
> this?
>

-- 
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 h2-database+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/h2-database/11a8614d-49c9-4c22-97be-cf32d1da34c7o%40googlegroups.com.

[h2] Re: Does MVStore make blocking IO calls?

[Andrei Tokar]

The short answer - it depends.

Majority of MVStore operations for in-memory case are non-blocking, 
especially if you use it in a low-contention scenario, but if you have many 
threads competing for doing some map updates, threads may yield, sleep or 
even go for lock acquisition after some failed non-blocking attempts. Your 
read operations are guaranteed to go non-blocking in any case.

Just curious, what you are trying to achieve with pure in-memory MVStore 
(without transactional functionality), that can not be done with stock JDK 
SortedMap implementations like TreeMap or ConcurrentSkipListMap?


On Friday, July 24, 2020 at 10:48:57 AM UTC-4, Vincent Ngan wrote:
>
> Hi,
>
> I like MVStore very much. It is just a great library for implementing 
> embedded key/value database solutions. I have also been using Kotlin for 
> development. One of the great things about Kotlin is its asynchronous 
> coroutines feature. In order to use Kotlin coroutines effectively, it is 
> important that your code does not do any synchronous blocking IO. I am not 
> sure whether I can use MVStore library safely in coroutines assuming that 
> it does not do synchronous blocking IO. It is obvious that when MVStore is 
> configured to use FileStore or OffHeapStore, some kind of system IO will be 
> incurred. But, what if I just use the in-memory part of MVStore without 
> configuring it with any FileStore? Does the pure in-memory part of MVStore 
> make any blocking system calls?
>
> Best regards,
> VN
>

-- 
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 h2-database+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/h2-database/6073ba22-0d19-42ad-8382-57c924f07af8o%40googlegroups.com.

[h2] Re: Release Schedule

[Andrei Tokar]

Hi Mark,

Unfortunately, there is no set release schedule for H2, and so far they 
have been happening in ad-hoc fashion, when Thomas Mueller finds a time to 
do so, since he is the only person.

-- 
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 h2-database+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/h2-database/fbef4d0e-4d69-4987-b8e2-efe203dda800%40googlegroups.com.

Re: [h2] Joining a table with itself is an issue?!

[Andrei Tokar]

I wonder how many rows do you expect to come back.
Even if you have 30 year of history in your table (an given a financial 
nature of your data
it can't be significantly longer than that), it would give us ~ 10,000 
dates, which would yield
100 rows per date on average.
Under such assumption join result might have 100,000,000 rows.
At least it has to be executed in a lazy fashion, but most likely you need 
some limiting conditions.

-- 
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 h2-database+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/h2-database/53344bf1-0da2-4b17-99ad-d72073e192d8%40googlegroups.com.

Re: [h2] Joining a table with itself is an issue?!

[Andrei Tokar]

I wonder how many rows do you expect to come back.
Even if you have 30 year of history in your table (an given a financial 
nature of your data
it can't be significantly longer than that), it would give us ~ 10,000 
dates, which would yield
100 rows per date on average.
Under such assumption join result might have 10,000,000,000 rows.
At least it has to be executed in a lazy fashion, but most likely you need 
some limiting conditions.

-- 
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 h2-database+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/h2-database/99d5ca04-5f9a-4445-8b11-a26afba755e7%40googlegroups.com.

[h2] Re: NPE after upgrade from H2 4.1.197 to any later version

[Andrei Tokar]

I can not reproduce it with current master branch (but easily in 1.4.200). 
Got to be fixed by now.

-- 
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 h2-database+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/h2-database/6cdacdd7-cab6-4135-808d-a0d120a41067%40googlegroups.com.

[h2] Re: compactRewriteFully ?

[Andrei Tokar]

The best result, if you are looking to minimize file size, would be 
off-line mode MVStoreTool.compact(), also available as command line utility.
If you are looking for the same in on-line mode (while MVStore is still 
open), than MVStore.compactFile() may be used.

-- 
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 h2-database+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/h2-database/bc64506d-b30d-421a-8be9-19e32eb8311b%40googlegroups.com.

[h2] Re: Chunk metadata too long

[Andrei Tokar]

First of all - it has nothing to do with disk space available. It is a bug 
in MVStore. When chunk is saved and insufficient space for chunk header is 
reserved at the beginning, but later when all chunk's data is written and 
it's time to write actual values into the header (and this is JSON-like 
formatted string with chunk attributes) it turn's out that reserved space 
is insufficient. Your massive entries removal indded may trigger that.  
Latest version (1.4.200) does more conservative estimate, so chance of this 
happening is reduced, but not eliminated. We just need to handle that 
condition in a more robust way (it is totally recoverable), instead of 
throwing the towel.

As far as automatic reopening goes - it not always a good idea, because 
root cause for premature closure could be anything. If you think that you 
need that, it can be easily implemented by application.

-- 
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 h2-database+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/h2-database/2a231bda-7be1-484d-8e30-edf43c20cee9%40googlegroups.com.

Re: [h2] 200 crash issue

[Andrei Tokar]

Knowing the changes that went into 1.4.200, let me disagree.
I suspect that split might be exactly the culprit here, another one might 
be a compression.

-- 
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 h2-database+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/h2-database/9b107df8-288b-4b45-b84a-633783453a7e%40googlegroups.com.

[h2] Re: Exclusive mode behavior change from 1.4.199 to 1.4.200

[Andrei Tokar]

I won't even try to defend this one. It is a bug, and fix is here. 


-- 
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 h2-database+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/h2-database/df858143-30ca-4ddb-8263-320be9b29566%40googlegroups.com.

[h2] Re: Exclusive mode behavior change from 1.4.199 to 1.4.200

[Andrei Tokar]

I know, I've read and run it, but my point is - it's not the connection 
that set exclusive mode, because there is none, exclusive mode is not set 
at all.

-- 
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 h2-database+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/h2-database/b619ebda-a67d-4b71-8be7-31dd2e6837af%40googlegroups.com.

[h2] Re: Exclusive mode behavior change from 1.4.199 to 1.4.200

[Andrei Tokar]

Although it is a departure from a previous behavior, this is expected, 
because documentation says:
Only the connection that set the exclusive mode can disable it 

At the point when test fails, exclusive mode is not set (or rather unset 
already), hence the failure.

-- 
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 h2-database+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/h2-database/b92b5a55-f7e0-4929-9a8e-754b6fdd09bc%40googlegroups.com.

Re: [h2] H2 inability to deal with interrupts

[Andrei Tokar]

Paul,

You are very welcome to read the code, understand it and write a little doc 
page about available options and trade-offs.
BTW, client-server IS a solution, which trades some performance for 
stability. It may be unsuitable in your situation, but you never bother to 
describe it either, so why do you expect that someone will spend time 
laying out all available options?. Nothing is free in this world! This 
includes all ACID properties performance and of course, software support.
You wrote to Noel, like you are holding some paid support contract with 
him. My apologies, it it is a case, but mostly people volunteer here and 
support other users on a "best effort" basis.

-- 
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 h2-database+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/h2-database/b4e8d6da-7181-4f0a-a258-ed205e036fc2%40googlegroups.com.

[h2] Memory increase after Update from 1.2 to 1.4.199

[Andrei Tokar]

It has been a change of the underlying storage engine used by default. You can 
try MV_STORE=false to stay with old pgstore.

-- 
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 h2-database+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/h2-database/485a9e90-5a08-4b25-b565-abd70ccb94c7%40googlegroups.com.

Re: [h2] Re: Corrupt Database Chunk Wont Recover

[Andrei Tokar]

You can get them from maven repo 
https://mvnrepository.com/artifact/com.h2database/h2.

So you did not like whatever I've recovered? I doubt that there is any more 
data in this file.

-- 
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 h2-database+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/h2-database/0e6ee188-edf8-4ce6-97ea-f4320dfb69d9%40googlegroups.com.

[h2] Re: Corrupt Database Chunk Wont Recover

[Andrei Tokar]

Please see attached my take on that recovery (after a few hacks in source 
code).

-- 
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 h2-database+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/h2-database/36d00b37-fb1c-4860-8fc4-2807649ccb62%40googlegroups.com.
<>

[h2] Re: Corrupted database (again) with h2-1.4.199

[Andrei Tokar]

Hi Silvio,

I just merged into master presumable fix for your issue 
, but I can not really 
verify that it works.
If you can rebuild h2 from master branch again and try to open that 
corrupted file...

-- 
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 h2-database+unsubscr...@googlegroups.com.
To post to this group, send email to h2-database@googlegroups.com.
Visit this group at https://groups.google.com/group/h2-database.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/h2-database/d69b6076-e774-4701-a33e-cf88dd9ffc5a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[h2] Re: Corrupted database (again) with h2-1.4.199

[Andrei Tokar]

Too bad 8-(
I was thinking about running recovery tool under debugger to see what's 
going on.

BTW, error from recovery is different from the one database it throwing. 
Recovery is saying that file was kind of illegally truncated and is too 
short now, while database is complaining about corrupted page.

But it is really weird, since 1.4.196 is fine in both cases.

What you can do though, so we do not chase black cat in a dark room, when 
it is not there, is to build from current git master branch 
http://h2database.com/html/build.html and see if problem is still there.

-- 
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 h2-database+unsubscr...@googlegroups.com.
To post to this group, send email to h2-database@googlegroups.com.
Visit this group at https://groups.google.com/group/h2-database.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/h2-database/380ae6b7-7a16-40e7-9d57-591661004982%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[h2] Re: Corrupted database (again) with h2-1.4.199

[Andrei Tokar]

Are there any chance, you can share original corrupted file?

-- 
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 h2-database+unsubscr...@googlegroups.com.
To post to this group, send email to h2-database@googlegroups.com.
Visit this group at https://groups.google.com/group/h2-database.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/h2-database/00f52ffe-a6d6-4c2e-b69a-f696f43ad8ce%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [h2] OutOfMemory when creating an Index

[Andrei Tokar]

Something does not click here:
If you have "a table with millions of rows and an assumed column width of 
4MB of data", then how it is possible, that
"with set to 1000 the index creation still required a maximum heap of about 
800M, but the OOM Error did not occur anymore" ?
Your thousand rows should take at least 4G of RAM, not 800M.

IMHO, index creation for a big table is an administrative task, presumably 
performed on idle (if not exclusively held) database,
so what would prevent you from opening db with MAX_MEMORY_ROWS of lets say 
3000 (assuming 4g heap), creating index, then restart database
with you favorite 10, for application to use?

On the other hand, we probably should select buffer size as SQRT(ROWCOUNT) 
and if it exeeds MAX_MEMORY_ROWS/2, then just fall back to plain vanilla r
ebuildIndexBuffered().
It might  take forever and will trash b-tree, but at least should not fail 
with OOM.

-- 
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 h2-database+unsubscr...@googlegroups.com.
To post to this group, send email to h2-database@googlegroups.com.
Visit this group at https://groups.google.com/group/h2-database.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/h2-database/212abf4b-e484-4253-92e2-5799166b1ce0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[h2] Re: Corrupted database (again) with h2-1.4.199

[Andrei Tokar]

Your stack trace indicates that database is starting, so it is not obvious 
that it happened "during normal production use of the system". It was shut 
down (possibly abruptly?) before this.
It was more than enough changes, of course, between 1.4.196 and 1.4.199, 
and many of them are targeted at providing a better throughput for your 99 
concurrent connections.
Unfortunately, it is extremely hard to find the issue without reliably 
reproducible test case, but if you have one...

-- 
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 h2-database+unsubscr...@googlegroups.com.
To post to this group, send email to h2-database@googlegroups.com.
Visit this group at https://groups.google.com/group/h2-database.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/h2-database/110f2838-1791-4e4d-b7e6-8037baee454a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [h2] Re: Recent drops in performance

[andrei . tokar]

Please keep in mind, that even for in-memory database, pgstore or mvstore 
are still very much in use.
So it looks like apples-to-oranges comparison indeed. To make them 
comparable I would switch to pgstore use in 1.4 versions, by explicitly 
specifying MVSTORE=FALSE in url.

-- 
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 h2-database+unsubscr...@googlegroups.com.
To post to this group, send email to h2-database@googlegroups.com.
Visit this group at https://groups.google.com/group/h2-database.
For more options, visit https://groups.google.com/d/optout.

Re: [h2] Re: Recent drops in performance

[andrei . tokar]

I wonder how your URL looks like and whether it is apples to oranges 
comparison, because default settings have changed between those versions, 
most notably default storage engine was pagestore in older versions vs 
mvsore in recent ones. That alone can have big performance impact. 

In any case, we still need your standalone test case

-- 
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 h2-database+unsubscr...@googlegroups.com.
To post to this group, send email to h2-database@googlegroups.com.
Visit this group at https://groups.google.com/group/h2-database.
For more options, visit https://groups.google.com/d/optout.

[h2] Re: Iterating cursor of a MVMap with multithread?

[Andrei Tokar]

"MV" stands for multi-version. Once you've created Cursor, it essentially 
will iterate over a snapshot of the map, so any subsequent updates by other 
threads (or even by the same thread) will not be visible. In your example 
cursor will happily discover key "1009".

-- 
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 h2-database+unsubscr...@googlegroups.com.
To post to this group, send email to h2-database@googlegroups.com.
Visit this group at https://groups.google.com/group/h2-database.
For more options, visit https://groups.google.com/d/optout.

[h2] Re: Efficient way to search for a row

[Andrei Tokar]

Why can't you select MAX(ID) and no ORDER BY, instead of fetching the first 
row of ordered select?

SELECT MAX(id)
FROM TRANSAKCJA
WHERE "DATA" <= '2019-01-18 00:00:00.0' 

-- 
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 h2-database+unsubscr...@googlegroups.com.
To post to this group, send email to h2-database@googlegroups.com.
Visit this group at https://groups.google.com/group/h2-database.
For more options, visit https://groups.google.com/d/optout.

Re: [h2] Errors when dumping database to SQL

[Andrei Tokar]

The issue https://github.com/h2database/h2database/issues/1691 
,
 
mensioned by Evgenij, is fixed now in master.

-- 
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 h2-database+unsubscr...@googlegroups.com.
To post to this group, send email to h2-database@googlegroups.com.
Visit this group at https://groups.google.com/group/h2-database.
For more options, visit https://groups.google.com/d/optout.

[h2] Re: Failed to use github newest code to open old .mv.db?

[Andrei Tokar]

Or buid H2 using jdk8, or even 7 instead of 10

-- 
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 h2-database+unsubscr...@googlegroups.com.
To post to this group, send email to h2-database@googlegroups.com.
Visit this group at https://groups.google.com/group/h2-database.
For more options, visit https://groups.google.com/d/optout.

[h2] cache size vs. disk size

[Andrei Tokar]

First of all, do not be surprized if your file will grow well beyond yor data 
size, so 500Mb should not be your guideline. As far as caching raw file data, 
OS will do a good job if memory is plentiful. H2 caches deserialized data 
pages, and it is definitely a waste try to cache all of that data, even 
infrequently used, or not at all. If performance is you concern, and you’ve got 
plenty of RAM, try incrementaly increase heap size (default cache size will 
increase accordingly), until you reach the point of diminishing return.

-- 
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 h2-database+unsubscr...@googlegroups.com.
To post to this group, send email to h2-database@googlegroups.com.
Visit this group at https://groups.google.com/group/h2-database.
For more options, visit https://groups.google.com/d/optout.

[h2] Re: MVStore cache memory usage greatly exceeding cacheSize setting

[Andrei Tokar]

>
> Hi Matthew, 
>
 
when you set your "cacheSize" to 96, what makes you to believe that actual 
memory consumption (retained size) would be ~ 96Mb? This is an  
*approximate* size of the *cached data, *which has some correlation with 
retained size, but that's about it. In the upcoming version (latest git 
code) there is even less guarantees, because cache will also keep some data 
weekly reachable, which would contribute to retained size (memory overhead 
of Map.Entry, WeakReference etc.) but not cached data size. This setting is 
just a "control gauge" for you to play with and to make a decision in 
memory vs. performance trade-off, and it has very little to do with actual 
memory consumption.

-- 
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 h2-database+unsubscr...@googlegroups.com.
To post to this group, send email to h2-database@googlegroups.com.
Visit this group at https://groups.google.com/group/h2-database.
For more options, visit https://groups.google.com/d/optout.

[h2] Re: autocommit=false slower than autocommit=true??

[Andrei Tokar]

No, performance suppose to be the same, if not faster, if you batch is not 
big. How do you measure it? what is the version you are using, and how url 
is look like? Can you produce standalone use case demonstrating slowness.

-- 
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 h2-database+unsubscr...@googlegroups.com.
To post to this group, send email to h2-database@googlegroups.com.
Visit this group at https://groups.google.com/group/h2-database.
For more options, visit https://groups.google.com/d/optout.

[h2] Re: General error: "java.lang.IllegalStateException: Chunk 2408 not found [1.4.197/9]"

[Andrei Tokar]

Hi Ivaylo,

It would be MUCH easier if you just post java code here instead.
BTW, table population with auto-commit on, no batches, and embedded data 
instead of prepared statement is not the fastest way of doing this, so when 
you say "the execution times for inserting the data were similar", it realy 
means "similarly terrible".

Going back to SELECT, my results for "SELECT * FROM TableB" execution time:

v. 1.4.197:
PgStore: 2.3 sec.
MVStore: 5.1 sec.

v. 1.4.198 SNAPSHOT, built from commit 
ac05e08c8aafe6d8680ec09b9b2ee371355ffb4c, which you mentioned (With latest 
snapshot results are similar):
PgStore: 2.4 sec.
MVStore: 1.2 sec.


It seems like there is absolutely nothing special about your test case, and 
results are consistent with what I posted above for some 7 column 30 
rows table of my own making. Most likely, when you was measuring time with 
some SQL client (Squirl ?), it does not pick up driver, you expect. Why not 
just run your test as standalone java program? And please build latest 
clean jar, by following instructions, because one you posted is a bit 
weird, even if you just look at it's directory listing.

The bottom line is: 
in 1.4.197 this select ~ 2 times slower with MVStore vs. PgStore, whereas 
in latest version it's 2 times faster.

Best of luck!
Andrei

-- 
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 h2-database+unsubscr...@googlegroups.com.
To post to this group, send email to h2-database@googlegroups.com.
Visit this group at https://groups.google.com/group/h2-database.
For more options, visit https://groups.google.com/d/optout.

[h2] Re: General error: "java.lang.IllegalStateException: Chunk 2408 not found [1.4.197/9]"

[Andrei Tokar]

Hi Ivaylo,
I am glad to hear that “Chunk not found” bug is no longer appear with latest 
build.
That other discussion, you have mentioned, is related to a different 
performance problem, and according to Noel Grandin has been addressed in latest 
build, as well.
Going back to your claim of slow “SELECT * FROM” - my experiments with 30 
rows, 7 column table shows that execution time with PageStore is prety much 
consistent across 1.3.175, 1.4.197 and latest snapshot. MVStore execution time 
in 1.4.197 is 1.5 times that, while in latest snapshot it’s 2.5 times faster 
than PgStore.
So, apparently your case is different from mine in some important aspects 
(indexes, constraints, column tipes). I am afraid, that until you can provide 
simple, standalone, reproducible test case, not much we can do here.

-- 
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 h2-database+unsubscr...@googlegroups.com.
To post to this group, send email to h2-database@googlegroups.com.
Visit this group at https://groups.google.com/group/h2-database.
For more options, visit https://groups.google.com/d/optout.

[h2] Re: General error: "java.lang.IllegalStateException: Chunk 2408 not found [1.4.197/9]"

[Andrei Tokar]

It depends what do you mean by "executing huge number of select 
statements". MVStore is somewhat slower than older PageStore 
(MV_STORE=FALSE) in a single-threaded scenario, but with latest changes 
(post 1.4.97) that gap is down to about 20-40%. But multi-threaded scenario 
is really where MVStore will shine (again in post 1.4.97). Try to build 
from source and see for yourself. Optimization of MVStore is not just on 
the TODO list for next release, many are out there already.

-- 
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 h2-database+unsubscr...@googlegroups.com.
To post to this group, send email to h2-database@googlegroups.com.
Visit this group at https://groups.google.com/group/h2-database.
For more options, visit https://groups.google.com/d/optout.

[h2] Re: General error: "java.lang.IllegalStateException: Chunk 2408 not found [1.4.197/9]"

[Andrei Tokar]

Hi Ivaylo,

Circumstances under which this bug will appear may vary greatly (because it 
is a fairly low-level problem), but I believe it is fixed after last 
release. If you can build H2 from the latest code, I would be very 
interested in your feedback about whether or not you problem is resolved, 
and if you still have a reproducible test case, I'll gladly take it from 
there.

Thanks,
Andrei

>
>

-- 
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 h2-database+unsubscr...@googlegroups.com.
To post to this group, send email to h2-database@googlegroups.com.
Visit this group at https://groups.google.com/group/h2-database.
For more options, visit https://groups.google.com/d/optout.

[h2] Re: deadlock in MVStore

[Andrei Tokar]

Hi Dan,

MVStore code has undergone significant changes since last release 
(especially in locking / synchronization area), and code referred to in you 
stack traces is simply not there anymore. Please try to build latest 
version and see if problem still there.  I would be very interested in any 
feedback.

Thanks,
Andrei

-- 
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 h2-database+unsubscr...@googlegroups.com.
To post to this group, send email to h2-database@googlegroups.com.
Visit this group at https://groups.google.com/group/h2-database.
For more options, visit https://groups.google.com/d/optout.

[h2] Re: best way to get an MV store to compact?

[Andrei Tokar]

Hi Dan,

I think that

MVStoreTool.compact(MVStore source, MVStore target)

will fit that bill perfectly.

Or you can just use command line like:

java -cp h2-1.4.197.jar org.h2.mvstore.MVStoreTool -compress 

-- 
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 h2-database+unsubscr...@googlegroups.com.
To post to this group, send email to h2-database@googlegroups.com.
Visit this group at https://groups.google.com/group/h2-database.
For more options, visit https://groups.google.com/d/optout.

[h2] Re: Table Not Found

[Andrei Tokar]

Make sure your current directory on JVM startup is AppDatabase. 
Connection is "Ok", because it probably creates a new empty database 
somwhere else under ./res/db/, whatever it is.

-- 
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 h2-database+unsubscr...@googlegroups.com.
To post to this group, send email to h2-database@googlegroups.com.
Visit this group at https://groups.google.com/group/h2-database.
For more options, visit https://groups.google.com/d/optout.

[h2] Re: Unable to execute queries concurrently in H2

[Andrei Tokar]

Leave you url as is and build H2 from latest source. There are significant 
changes in concurrency/scalability area. 

-- 
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 h2-database+unsubscr...@googlegroups.com.
To post to this group, send email to h2-database@googlegroups.com.
Visit this group at https://groups.google.com/group/h2-database.
For more options, visit https://groups.google.com/d/optout.

Re: [h2] MVStore and interrupts?

[Andrei Tokar]

Hi Dan, with respect to version management in MVStore, there are significant 
differences between 1.4.197 release and trunk, that’s why I would recommend to 
check out latest code.
Number of versions kept in a file-based store is determined by usage. In 
absense of registerVersionUsage() / deregisterVersionUsage() calls, only latest 
version will be kept. This is only safe to do in a single-threaded scenario 
without auto-commit. Once you have more than one thread (including background 
auto-commit one), “current” version may be not what you think it is, and your 
operation, i.e. map iteration via cursor, may fail due to the fact that version 
it was iterating on, has been removed. That is why interest in specific version 
(and coincidentally all subsequent ones) should be expressed via 
registerVersionUsage().
In addition, time-based policy may be used with setRetentionTime(), but it 
never be 100% reliable, and mainly exists for usage simplicity and backward 
compatibility.
You may call compactMoveChunks() if you want, but that not strictly necessary, 
because space occupied by unused versions will be eventually re-used.

-- 
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 h2-database+unsubscr...@googlegroups.com.
To post to this group, send email to h2-database@googlegroups.com.
Visit this group at https://groups.google.com/group/h2-database.
For more options, visit https://groups.google.com/d/optout.

[h2] Re: Unknown data type: "TINYINT"

[Andrei Tokar]

Does it work for you if CREATE statement is executed directly from web 
console?
I was not able to reproduce it.

-- 
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 h2-database+unsubscr...@googlegroups.com.
To post to this group, send email to h2-database@googlegroups.com.
Visit this group at https://groups.google.com/group/h2-database.
For more options, visit https://groups.google.com/d/optout.

Re: [h2] NPE in simple Common Table Expression

[Andrei Tokar]

I think @stumc need to take a second look at this because problem still exists 
in master. It seems like TableView is released prematurely and 
ResultSetMetaData can not be constructed.

-- 
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 h2-database+unsubscr...@googlegroups.com.
To post to this group, send email to h2-database@googlegroups.com.
Visit this group at https://groups.google.com/group/h2-database.
For more options, visit https://groups.google.com/d/optout.

Re: [h2] ENUM data type is not nullable?

[Andrei Tokar]

Hi Nikita, 

Just posted a pull request to fix enum nullability issue.
https://github.com/h2database/h2database/pull/615
Problem was actually not just with select, but with insert as well. 

Thanks for taking time to report and troubleshoot this problem!

-- 
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 h2-database+unsubscr...@googlegroups.com.
To post to this group, send email to h2-database@googlegroups.com.
Visit this group at https://groups.google.com/group/h2-database.
For more options, visit https://groups.google.com/d/optout.

[h2] Re: MVStore.compactMoveChunks() problem

[Andrei Tokar]

Hi Roland,

I think, your test case reveals the bug in MVStore, but it is not directly 
related to MVStore.compactMoveChunks(). 
I have created pull request 
 to fix it, but since I 
am not an author of this code, I might be wrong. Let's see how it goes.

Best Regards,
Andrei

>
>

-- 
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 h2-database+unsubscr...@googlegroups.com.
To post to this group, send email to h2-database@googlegroups.com.
Visit this group at https://groups.google.com/group/h2-database.
For more options, visit https://groups.google.com/d/optout.