| Gerhard | Hi all, frequent problem with an old OpenRoad 4.0 application: locally installed on many PCs --> locally installed symbol.tbl files --> troubles because of different Ingres variables... | 01:01 |
|---|---|---|
| Gerhard | I'm thinking about writing some kind of script... | 01:03 |
| Gerhard | ingcompenv PC1 PC2 PC3... | 01:04 |
| *** Mud|game has joined #ingres | 01:04 | |
| Gerhard | that will invoke an "ingprenv | sort" on all the PCs, somehow parse the results, save it to a .CSV which can be displayed in Excel | 01:06 |
| Gerhard | Before I start: is such a tool already available...? | 01:06 |
| grantc | Gerhard, i'm not aware of such a beast. you might want to chat with support as they may have instructions on setting up ingres in a common environment | 01:07 |
| Gerhard | Good idea. | 01:08 |
| grantc | i know it used to be possible ala NFS but I don't know if it is possible still | 01:09 |
| grantc | there are tricks you can do with the config.dat to simplify things but I don't know about symbol.tbl | 01:09 |
| Vroomfondle | grantc: I've not used prepared statements before. If I set up a bunch of them (the PHP manual seems to suggest that this adds them all to the same transaction), then I execute a non-prepared statement using ingres_query with autocommit on, am I going to effectively close all my prepared statements? Or will a new transaction be opened when I pass them to ingres_execute? | 01:18 |
| grantc | until you do the commit they form part of the same transaction | 01:19 |
| grantc | you should not be able to auto commit with existing active statements | 01:19 |
| Vroomfondle | I see | 01:20 |
| grantc | the same if you do queries in tm/sql and then exectute "set autocommit on" | 01:21 |
| grantc | i cannot remember if the driver checks to see if there is a transaction in effect or if there are active statements but the dbms server would kick you back | 01:21 |
| grantc | the driver blocks auto commit with active statements (just re-read the source) | 01:24 |
| Vroomfondle | but if I do an ingres_commit() manually, all my open prepared statements will be closed? | 01:25 |
| Vroomfondle | basically I'm wondering if one can set up a central pool of common statements which can be used by $whichever_script as the user navigates around the site. However if an ingres_commit() is going to close all open statements then I guess that's not going to work very well. | 01:27 |
| grantc | there's no guarantee you will be served by the same thread/process for each http request | 01:32 |
| Vroomfondle | true. | 01:32 |
| Vroomfondle | Yeah, it's probably not such a good idea in general. | 01:32 |
| *** PaulM05 has joined #ingres | 01:50 | |
| *** Gerhard has quit IRC | 01:50 | |
| *** raial01 has joined #ingres | 02:22 | |
| Vroomfondle | grantc: is there any way to check if a prepared statement is still valid (i.e. the transaction hasn't been committed), other than trying to use it and checking for an error? | 02:32 |
| *** cthibert has joined #ingres | 03:35 | |
| Vroomfondle | is there any documentation on cache_dynamic? I can't seem to find anything in the manual. I just want to check I'm not re-inventing the wheel. | 04:16 |
| PaulM05 | the only thing I'm aware of is the HELP in CBF | 04:32 |
| Vroomfondle | well... I guess that all I really want to know is that if I prepare a statement, then commit, does the QEP get wiped from the cache? i.e. do I need to avoid committing until I've finished using and re-using the statement? | 04:34 |
| PaulM05 | I don't know (but I would hope not) | 04:34 |
| Vroomfondle | I'm basing my work on the way that a colleague does it, but he uses MySQL | 04:35 |
| PaulM05 | IIRC cache_dynamic was supposed to be like REPEATED for dynamic SQL, so *assuming* it works the same way, the QEP would be flushed eventually on an LRU basis | 04:37 |
| Vroomfondle | he keeps a central pool of prepared statements in his app, then each time his app wants to do something it looks in the pool for the required statement and executes it with the required parameters. Do I actually need to keep my own pool like that, or can I just rely on Ingres to notice that the statement currently being prepared matches one that was prepared a little while ago... | 04:37 |
| pboro | Vroomfondle, a small warning about dynamic_cache and LOBs... there are currently bugs in the dynamic_cache which cause errors in errlog.log and may hang the dbms under stress | 04:38 |
| Vroomfondle | what's a LOB, exactly? | 04:38 |
| pboro | Vroomfondle, large binary object, i.e. LONG VARCHAR or LONG BINARY | 04:38 |
| Vroomfondle | oh right, I see | 04:38 |
| Vroomfondle | we don't use those, fortunately, but I will make a note of it for the future in case we want to start | 04:39 |
| pboro | are you using java? | 04:39 |
| Vroomfondle | No, PHP | 04:39 |
| pboro | ah, ok | 04:39 |
| grantc | Vroomfondle, sorry I had to pop out - there is no real way to know if a prepared statement is still valid | 04:44 |
| Vroomfondle | Okay. I'll just remember not to commit the transaction until I'm done with the statement. | 04:45 |
| Vroomfondle | Do you have any views on what I said at 12:37? | 04:45 |
| Vroomfondle | I'm really not sure if I'm doing things the right way here or if I'm just writing unnecessary code | 04:45 |
| grantc | regarding cache_dynamic? I don't know if there is a way to know for sure if your QEP is still in QSF or not but it would be expensive to find out. | 04:47 |
| grantc | versus the cost of running the query, which you are going to do anyway ... :) | 04:48 |
| Vroomfondle | tbh I'm not even sure if I'm using ingres_prepare correctly, really. Is the idea: call it, store the result in a variable, then repeatedly pass that result to ingres_execute with different parameters each time? | 04:50 |
| grantc | sounds good to me | 04:51 |
| Vroomfondle | Right. And once I've committed the transaction, I should through away the result identifier because it's presumably now useless as it belongs to a completed transaction. | 04:51 |
| *** cthibert has left #ingres | 04:52 | |
| grantc | correct - the driver closes all open statements, free's all the active result resources associated with the link/connection and then commits | 04:54 |
| Vroomfondle | Okey-doke. I'll write my code so that it prepares its statements, executes them repeatedly as necessary, then commits once it's finsihed, and then clears its "pool" of prepared statements to make sure they don't get accidentally re-used later. | 04:55 |
| Vroomfondle | all this in the name of showing off | 04:55 |
| Vroomfondle | still, we've a departmental restructuring coming up so brownie points are worth having ;) | 04:56 |
| *** cthibert has joined #ingres | 04:56 | |
| grantc | you could execute the same statements via ingres_query() and compare the difference in speed vs prepare + execute/execute/execute/execute/execute/execute | 04:57 |
| grantc | i would be interested in general numbers as it's not something i've tested yet | 04:57 |
| *** Mud|game is now known as Mud | 04:58 | |
| Vroomfondle | I'm still waiting for admins to switch cache_dymanic on but yeah, once they've done that I'll knock up a quick test-script | 04:58 |
| grantc | cheers | 05:00 |
| *** PaulM05 is now known as PaulM05_lunch | 05:12 | |
| *** zxiiro has quit IRC | 05:14 | |
| *** Dejan has joined #ingres | 05:15 | |
| Dejan | hello | 05:15 |
| grantc | morning | 05:15 |
| *** Alex| has quit IRC | 05:36 | |
| *** atrofast has quit IRC | 05:42 | |
| *** atrofast has joined #ingres | 05:45 | |
| *** zxiiro has joined #ingres | 06:01 | |
| *** ChanServ sets mode: +v zxiiro | 06:01 | |
| Vroomfondle | ew, nasty | 06:04 |
| Vroomfondle | *** glibc detected *** /usr/sbin/apache2: double free or corruption (out): 0x00007fde5bc18d80 *** | 06:04 |
| Vroomfondle | ======= Backtrace: ========= | 06:04 |
| Vroomfondle | /lib/libc.so.6[0x7fde5a591dd6] | 06:04 |
| Vroomfondle | /lib/libc.so.6(cfree+0x6c)[0x7fde5a59670c] | 06:04 |
| Vroomfondle | /usr/lib/php5/20060613/ingres.so[0x7fde53d832bd] | 06:04 |
| Vroomfondle | that happens when I try to execute a prepared query on Ingres 9.2, PHP5, driver 2.2.1 | 06:04 |
| atrofast | Vroomfondle: Hack for workaround: export MALLOC_CHECK_=0 :D | 06:04 |
| Vroomfondle | heh | 06:05 |
| grantc | Vroomfondle, if you configure the driver using "CFLAGS=-g ./configure" then do make... you'll get a line number in ingres.c where that is happening | 06:06 |
| *** rossand has joined #ingres | 06:09 | |
| *** ChanServ sets mode: +o rossand | 06:09 | |
| Vroomfondle | k, will try that | 06:09 |
| *** PaulM05_lunch is now known as PaulM05 | 06:13 | |
| Vroomfondle | annoyingly, it now doesn't give any backtrace at all | 06:19 |
| Vroomfondle | it just hangs and my local copy of the web app becomes useless until I restart apache | 06:19 |
| Vroomfondle | the problem seems to be in ingres_execute | 06:19 |
| grantc | test case please :) | 06:23 |
| *** grantc is now known as grantc|afk | 06:27 | |
| * grantc|afk is away: Away | 06:27 | |
| *** Gerhard has joined #ingres | 06:34 | |
| *** Gerhard has quit IRC | 06:44 | |
| *** grantc|afk is now known as grantc | 07:11 | |
| * grantc is back (gone 00:44:20) | 07:11 | |
| *** cthibert has left #ingres | 07:12 | |
| *** cthibert has joined #ingres | 07:17 | |
| Vroomfondle | Hmm. Can't log in to service-desk. | 07:17 |
| Vroomfondle | even after a password reset. | 07:17 |
| *** ccsidiot has joined #ingres | 07:21 | |
| ccsidiot | Hello everyone :) I was doing some code reading under the src of geospatial, I'm just wondering what's WKB? | 07:56 |
| atrofast | Well Known Binary | 08:00 |
| atrofast | ccsidiot: http://en.wikipedia.org/wiki/Well-known_text | 08:00 |
| ccsidiot | :) Cool, thanks! | 08:04 |
| atrofast | Why would you get this error on an update statement? An error occurred when attempting to create or alter a table. The specified row size exceeded the maximum allowable row width | 08:20 |
| PaulM05 | max_tuple_length is too small for the row width you want | 08:21 |
| atrofast | Ah thanks PaulM05 | 08:21 |
| PaulM05 | if you set it to 0 it'll use the maximum possible for the page size | 08:22 |
| atrofast | That's good to know, thanks PaulM05... I've never run into that error before for some reason | 08:22 |
| PaulM05 | it happened on an update? was it an update ... from? | 08:24 |
| atrofast | No update table set (long list of sets) where blah | 08:25 |
| atrofast | I put max_tuple_length at 0 and it still gives me the error | 08:25 |
| atrofast | It only just started after I added ONE more column to the set | 08:25 |
| PaulM05 | did you re-start the DBMS? | 08:26 |
| atrofast | Yes | 08:26 |
| PaulM05 | what's the full error number (E_..) | 08:27 |
| * Vroomfondle gives up on prepared statements for the moment | 08:28 | |
| atrofast | E_US07FD | 08:28 |
| Vroomfondle | grantc: I've been struggling to come up with a reliable test-case; will have another go at it next week and let you know. Errors only seem to occur when cache_dynamic is turned on and prepared statements are used. Even after re-configuring with the CFLAG you gave me it still won't give me a line-number. *shrug*. | 08:29 |
| grantc | try --enable-debug as well with configure | 08:30 |
| Vroomfondle | annoyingly, whilst my main code crashes & burns my test code (which follows the same structure, at least in theory) runs just fine | 08:30 |
| Vroomfondle | okay, I'll try that tomorrow | 08:30 |
| PaulM05 | not sure what's happening there atrofast - if you can reproduce it reliably might be worth raising a bug | 08:42 |
| atrofast | Thanks for your help PaulM05 | 08:43 |
| Vroomfondle | woohoo! | 08:54 |
| Vroomfondle | grantc: I think I've identified the problem, ish | 08:54 |
| Vroomfondle | grantc: I was using xdebug for profiling. If I tell PHP not to load xdebug.so, Ingres prepared statements seem to work. | 08:54 |
| grantc | interesting | 08:55 |
| Vroomfondle | xdebug kind of inserts itself into the call-stack before the ingres functions are called: | 08:55 |
| Vroomfondle | /usr/lib/php5/20060613/ingres.so[0x7fde53d7b928] | 08:55 |
| Vroomfondle | /usr/lib/php5/20060613/ingres.so[0x7fde53d7c1bb] | 08:55 |
| Vroomfondle | /usr/lib/php5/20060613/ingres.so(zif_ingres_commit+0xc7)[0x7fde53d86548] | 08:56 |
| Vroomfondle | /usr/lib/php5/20060613/xdebug.so(xdebug_execute_internal+0x166)[0x7fde53375b33] | 08:56 |
| Vroomfondle | oh... poo | 08:58 |
| Vroomfondle | no wonder if worked. cache_dynamic's been turned off. | 08:58 |
| Vroomfondle | Damn. I thought I'd be able to go home on a high today :/ | 08:58 |
| *** Alex| has joined #ingres | 08:59 | |
| *** ChanServ sets mode: +o Alex| | 08:59 | |
| Vroomfondle | Meh. Now I'm all dissapointed. Ah well, home time. | 09:00 |
| atrofast | grantc: Does the php driver have something like Ingres_escape_string function? | 09:28 |
| grantc | rtfm :) | 09:28 |
| atrofast | Yeah found it, thanks :) | 09:29 |
| atrofast | grantc: What if I don't have a link yet? | 09:31 |
| grantc | no go | 09:33 |
| atrofast | Darn | 09:33 |
| atrofast | Okay thanks | 09:33 |
| *** raial01 has left #ingres | 09:37 | |
| *** Dejan has quit IRC | 10:12 | |
| *** atrofast has quit IRC | 10:16 | |
| *** atrofast has joined #ingres | 10:18 | |
| *** ccsidiot has quit IRC | 10:25 | |
| *** PaulM05 has quit IRC | 10:45 | |
| *** ii_log has joined #ingres | 11:23 | |
| *** Mud has quit IRC | 11:49 | |
| *** zxiiro has quit IRC | 13:29 | |
| *** Alex| has quit IRC | 13:38 | |
| *** cthibert has left #ingres | 13:50 | |
| *** DarylM has quit IRC | 13:53 | |
| *** ccsidiot has joined #ingres | 14:05 | |
| *** pboro has quit IRC | 14:11 | |
| *** pboro has joined #ingres | 14:16 | |
| *** zxiiro has joined #ingres | 15:52 | |
| *** ChanServ sets mode: +v zxiiro | 15:52 | |
| *** rossand has quit IRC | 17:21 | |
| *** cytrinox_ has joined #ingres | 19:21 | |
| *** cytrinox has quit IRC | 19:21 | |
| *** cytrinox_ is now known as cytrinox | 19:21 | |
| *** pboro has quit IRC | 19:39 | |
| *** dyki has quit IRC | 19:39 | |
| *** ccsidiot has quit IRC | 19:39 | |
| *** pboro has joined #ingres | 19:40 | |
| *** ccsidiot has joined #ingres | 19:40 | |
| *** dyki has joined #ingres | 19:40 | |
| *** grantc has quit IRC | 22:06 | |
| *** ccsidiot has left #ingres | 22:14 | |
| *** Mud|game has joined #ingres | 22:25 | |
| *** Alex| has joined #ingres | 22:35 | |
| *** ChanServ sets mode: +o Alex| | 22:35 | |
| *** tc has joined #ingres | 22:47 | |
| *** Mud|game is now known as Mud | 22:51 | |
| *** tc has quit IRC | 23:02 | |
| *** Alex| has quit IRC | 23:13 | |
| *** withdefault has joined #ingres | 23:24 | |
| *** ChanServ sets mode: +o withdefault | 23:25 | |
| *** Alex| has joined #ingres | 23:29 | |
| *** ChanServ sets mode: +o Alex| | 23:29 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!