*** grantc has joined #ingres | 00:14 | |
*** grantc has quit IRC | 00:17 | |
*** grantc has joined #ingres | 00:18 | |
*** KermitTheFragger has joined #ingres | 00:53 | |
*** Dejan has joined #ingres | 01:16 | |
*** grantc has quit IRC | 01:44 | |
Dejan | hello everybody | 01:46 |
---|---|---|
*** grantc has joined #ingres | 01:49 | |
Dejan | grantc, \o/ | 01:53 |
grantc | morning | 01:53 |
Dejan | brb | 01:54 |
*** Dejan has quit IRC | 01:54 | |
*** Dejan has joined #ingres | 02:22 | |
Dejan | \o/ | 02:22 |
pboro | good day | 02:40 |
Dejan | yeah | 02:41 |
Dejan | very nice day | 02:41 |
Dejan | guys, i wonder if Ingres has something similar to MySQL's unix socket domain for connecting to the local database? | 02:46 |
Dejan | i usually connect to /opt/mysql/mysql.sock or somilar | 02:46 |
Dejan | s/somilar/similar/ | 02:46 |
Dejan | instead of using "localhost" | 02:47 |
grantc | it's possible by using domain sockets rather than TCP/IP for the interconnect | 02:49 |
grantc | i think setting II_GC_PROT=UNIX will do what you want | 02:52 |
*** javahorn has joined #ingres | 04:10 | |
*** javahorn has left #ingres | 04:25 | |
*** gerhard has joined #ingres | 04:58 | |
*** atrofast has joined #ingres | 05:03 | |
*** cthibert has joined #ingres | 05:29 | |
Dejan | that is brilliant | 06:24 |
Dejan | i am going to investigate | 06:24 |
Dejan | too bad JDBC probably cannot use that... | 06:24 |
pboro | sockets fit badly to JDBC anyway, since you always need JNI... | 06:26 |
pboro | it's not very portable :) | 06:26 |
*** DarylM has joined #ingres | 06:27 | |
*** gerhard has quit IRC | 07:14 | |
*** Alex| has quit IRC | 07:47 | |
*** mull has joined #ingres | 08:00 | |
*** Mud has quit IRC | 08:15 | |
*** cthibert has left #ingres | 08:18 | |
*** Mud has joined #ingres | 08:22 | |
*** Mud has quit IRC | 08:28 | |
*** Mud has joined #ingres | 08:37 | |
*** rossand has joined #ingres | 08:42 | |
*** ChanServ sets mode: +o rossand | 08:42 | |
*** cthibert has joined #ingres | 09:44 | |
*** Mud is now known as Mud|shower | 09:47 | |
*** Alex| has joined #ingres | 09:52 | |
*** ChanServ sets mode: +o Alex| | 09:52 | |
atrofast | If you have a VARCHAR(5) column and try to insert 'hello!' (6 chars) Ingres just truncates it... is there any setting that will make Ingres fail instead? | 09:56 |
*** Dejan has quit IRC | 10:08 | |
pboro | atrofast, I would like that too | 10:10 |
atrofast | GeoTools expects it to fail, not to "silently apply voodoo magic and make it work" :P | 10:10 |
pboro | you got the locking problem solved? | 10:11 |
atrofast | Nope, still thinking about it | 10:11 |
pboro | okay | 10:11 |
atrofast | I'm just making sure everything else works while I do | 10:11 |
grantc | atrofast, what interface are you using to insert the varchar value? | 10:18 |
atrofast | JDBC | 10:19 |
atrofast | Does it have a setting to disallow that? | 10:19 |
grantc | nope | 10:21 |
grantc | the das server has no support for the feature | 10:21 |
grantc | i'm not sure any driver does, OpenAPI has a connection option | 10:21 |
grantc | i lie - ODBC has it enabled | 10:22 |
*** KermitTheFragger has quit IRC | 10:23 | |
pboro | hmm JDBC Spec is a bit vague about the case | 10:25 |
pboro | it's prolly up to SQL standard... | 10:28 |
*** Mud|shower is now known as Mud | 10:37 | |
atrofast | grantc: So ODBC disallows inserts longer than the column length? | 11:33 |
*** clach04 has joined #ingres | 11:36 | |
atrofast | Is there a way to make Ingres simulate this behaviour: a program opens a transaction, reads a table, then opens another transaction as a copy of the first one, the first transaction writes a new value to the table, the old transaction is supposed to still have the old value in it but it does not for some reason, it re-reads the new value or some such | 12:00 |
pboro | you need cursors for simulating the java behaviour, so you would probably need to do it in esql :/ | 12:01 |
atrofast | embedded sql? | 12:03 |
pboro | yeah, as far as I know esql can use cursors | 12:04 |
pboro | in isql/sql it's not possible afaik | 12:04 |
pboro | the other way would be writing it using jdbc to create a simple test case | 12:04 |
pboro | if you can provide me the sql sentences in question, I'm happy to write a such small program | 12:04 |
pboro | oops, hmm | 12:05 |
pboro | I probably misread your question... | 12:05 |
pboro | what isolation level are you using in the transactions? and are you using mvcc or not? | 12:05 |
pboro | and do you commit in either of the transactions? | 12:06 |
atrofast | Well it's all part of the GeoTools back end... if you look here: http://svn.osgeo.org/geotools/trunk/modules/library/jdbc/src/test/java/org/geotools/jdbc/JDBCFeatureStoreTest.java @ testAddInTransaction | 12:07 |
atrofast | This test fails: assertEquals(3, featureStore2.getFeatures().size()); | 12:07 |
atrofast | I've tried all isolation levels, none make a difference, and if I don't have readlock = nolock it will hang on the write | 12:07 |
pboro | do you have mvcc enabled? | 12:07 |
atrofast | No... for some reason it says it's not a valid lockmode level, whawt SVN revision did it go in? | 12:08 |
atrofast | The geospatial branch is pretty up to do date but my build might be slightly out of date | 12:08 |
pboro | don't know :/ "The feature is available for early testing starting in community edition build 117 of Ingres 10" | 12:08 |
atrofast | Okay I'll see if I can track it down | 12:09 |
pboro | readlock=nolock is prolly your problem atm | 12:09 |
atrofast | But it hangs completely without it :( | 12:10 |
pboro | since the lock is supposed to protect the value from getting read by other transactions before its commited | 12:10 |
atrofast | Okay MVCC is in geospatial branch, but my current install is out of date... let me reinstall ingres | 12:10 |
pboro | from http://community.ingres.com/wiki/MVCC_User_Guide#What_To_Expect_When_Using_MVCC | 12:11 |
pboro | "if user 1 is using traditional locking, then the read from x2 will also see the newly inserted row. But that's because user 1 has to wait until the update transaction commits in order to acquire a lock on x2" | 12:11 |
pboro | prolly cause you have readlock=nolock, there's no lock acquirement and you get to see the new value :/ | 12:13 |
pboro | without readlock=nolock it should stall until the updating transaction commits | 12:13 |
pboro | which probably causes a deadlock for Geotools, 'cos it expects mvcc features... | 12:13 |
atrofast | Yup that's my theory as well at this point | 12:13 |
atrofast | Let's see what happens with MVCC once I get the latest checkout compiled | 12:14 |
atrofast | And installed | 12:14 |
atrofast | And set up | 12:14 |
atrofast | And started | 12:14 |
pboro | Problems ahead? :) has it been long since you last merged? | 12:14 |
atrofast | Oh no the merge is all done, I just had a slightly out of date install :) | 12:14 |
pboro | ahhh okay :) | 12:15 |
atrofast | mvcc worked pboro | 12:34 |
pboro | did the test work too? | 12:34 |
atrofast | Yup it passed | 12:34 |
pboro | \o/ | 12:35 |
pboro | did you drop readlock=nolock too? | 12:35 |
atrofast | Yup readlock=shared now | 12:35 |
atrofast | Default value | 12:35 |
atrofast | Thanks a lot for helping me out, it's greatly appreciated | 12:36 |
pboro | no prob, I've run to same kind of problems because of programs made to expect mvcc :) | 12:37 |
pboro | at least you will be testing the mvcc stuff in ingres too :D | 12:37 |
atrofast | Yeah I love being able to port against the latest and greatest Ingres... :) | 12:41 |
pboro | did the whole test suite complete without errors? | 12:55 |
atrofast | Nah there are still issues but concurrency isn't really one of them at this point | 13:13 |
atrofast | There are hundreds of tests and I'd say about 90% pass at this point | 13:13 |
pboro | 90% is pretty good amount anyway | 13:14 |
*** cthibert has left #ingres | 13:33 | |
*** Mud has quit IRC | 13:37 | |
*** Alex| has quit IRC | 13:50 | |
*** grantc has quit IRC | 14:03 | |
*** grantc has joined #ingres | 14:41 | |
*** mull has quit IRC | 14:45 | |
*** mull has joined #ingres | 15:51 | |
*** mull has quit IRC | 16:56 | |
*** grantc has quit IRC | 17:04 | |
*** mull has joined #ingres | 17:52 | |
*** atrofast has quit IRC | 18:37 | |
*** rossand has quit IRC | 19:21 | |
*** cytrinox has quit IRC | 19:23 | |
*** cytrinox has joined #ingres | 19:25 | |
*** mull has quit IRC | 20:44 | |
*** grantc has joined #ingres | 22:02 | |
*** Alex| has joined #ingres | 22:39 | |
*** ChanServ sets mode: +o Alex| | 22:39 | |
*** Alex| has quit IRC | 23:18 | |
*** Alex| has joined #ingres | 23:34 | |
*** Alex| has joined #ingres | 23:34 | |
*** ChanServ sets mode: +o Alex| | 23:34 | |
*** lafille has joined #ingres | 23:45 | |
*** lafille has quit IRC | 23:46 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!