*** stliu has joined #ingres | 03:16 | |
*** Alex| has joined #ingres | 04:39 | |
*** ChanServ sets mode: +o Alex| | 04:39 | |
*** Alex| has quit IRC | 05:21 | |
*** stliu has quit IRC | 05:25 | |
*** stliu has joined #ingres | 05:37 | |
*** stliu has quit IRC | 06:27 | |
*** Mud has joined #ingres | 07:07 | |
*** Mud is now known as Guest30760 | 07:08 | |
*** Guest30760 has quit IRC | 07:20 | |
*** Guest30760 has joined #ingres | 07:26 | |
pboro | wtf... does Ingres enforce NOT NULL on UNIQUE columns? | 07:27 |
---|---|---|
pboro | apparently... "E_PS0480 ... All columns in a UNIQUE constraint MUST be created as NOT NULL." | 07:29 |
Vroomfondle | aye | 07:35 |
Vroomfondle | does anyone here know of any circumstances under which ingstop will fail to stop iidbms processes? It looks like they got orphaned somehow, or something like that. | 07:36 |
Vroomfondle | when we did an ingstart afterwards the whole Ingres system collapsed ten minutes later - we've just had to do a DR | 07:36 |
pboro | Vroomfondle, I have read that when forcibly shutting down Ingres for example using kill or similar it is then necessary to run ingstop to clean up some semaphores and ipcs | 07:59 |
pboro | ...before trying to start it again I meant | 08:00 |
Vroomfondle | so ingstop -force, then a normal ingstop? | 08:01 |
pboro | yup | 08:01 |
pboro | I have seen cases where ingstop -force have not been enough to stop ingres... but there's a -kill switch too! ;) | 08:01 |
Vroomfondle | we usually use -kill, but in this case we used -force | 08:02 |
Vroomfondle | so maybe that was a mistake | 08:02 |
pboro | iirc -force tries first to shut down ingres "normally" and if it fails, it kills it | 08:03 |
pboro | and -kill kills ingres immediately, without first trying the normal way | 08:03 |
pboro | hmm, no... | 08:05 |
pboro | "-force Forces the shut down of active servers in the installation without waiting for users to disconnect." | 08:05 |
Vroomfondle | yeah, I think -force kills the sessions "cleanly" first, then shuts down the server | 08:06 |
pboro | normal shutdown fails if there's active connections, -force closes the connections and then does a normal shutdown | 08:06 |
pboro | yeah, that's right | 08:06 |
pboro | you should not need to run ingstop again after successful ingstop -force | 08:06 |
pboro | and afaik -force should not cause any problems for the dbms itself (clients may be unhappy...) | 08:07 |
Vroomfondle | what happened for us, as far as we can tell, is that -force seemed to complete successfully but that there were still two iidbms processes running afterwards | 08:45 |
Vroomfondle | which we didn't notice, and neither did ingstart. It spun up two more and then we ended up with two RCPs trying to cover the same databases, which lead to a double-open and the databases got marked as inconsistent | 08:46 |
pboro | ok, sounds pretty nasty... | 12:52 |
Vroomfondle | Aye. We cut our losses and spun up our 'warm backup' server pretty-much immediately. Now we're trying to do a post-mortem. | 12:58 |
Vroomfondle | naturally it happened during the most important week of the year for this particular system | 12:58 |
Vroomfondle | somehow I think it knew... | 12:59 |
pboro | :D | 12:59 |
pboro | is the particular system called... Skynet? | 12:59 |
pboro | "Columns that you specify as Unique or that you use as part of a table-level Unique constraint cannot be nullable." -- http://docs.ingres.com/ingres/10.0/database-administrator-guide/1907-unique-constraints?hilite=UNIQUE | 13:34 |
pboro | damn... | 13:34 |
Vroomfondle | I suppose from a compsci point of view that makes sense. Something has to have a value in order to be unique, and nulls have no value. Still a little bit crap from a practical point of view though ;) | 13:45 |
pboro | SQL 92 allows nulls for unique columns | 13:46 |
pboro | and so do: Oracle, MS SQL, PostgreSQL, MySQL, ... | 13:46 |
pboro | it's a pain in the arse to port applications onto Ingres :D | 13:46 |
DarylM | SQL is so fragmented it is a pain to port anything to anything else. | 14:40 |
pboro | true, true... | 14:40 |
pboro | all the vendor extensions, nnngh :) | 14:40 |
DarylM | AHA. This must be from Roy's forum post | 15:01 |
pboro | ? | 15:03 |
DarylM | null unique keys | 15:03 |
pboro | oh, there's a forum post about it? lemme search it :) | 15:03 |
DarylM | LOL | 15:04 |
pboro | wow, just the same time as I was having problems with it :o | 15:06 |
pboro | miracle... | 15:06 |
DarylM | Interesting definition of a miracle :D | 15:06 |
pboro | I started to wonder the topic over 7 hours ago, Roy posted about it 4 hours ago... HMMM :) | 15:07 |
pboro | hehe | 15:12 |
pboro | the example of different kind of IDs (like passport no, driver licence no, etc) is exactly the case in the program I'm porting | 15:13 |
pboro | the other way around would be to have another table which would contain those, but if there's billions of rows, it's a bit pitty to repeat the id of the entity for the sake of non-nullable uniques | 15:14 |
DarylM | We need to draw the distinction between what is the right was to architect a system and the needs of someone porting existing software. | 15:15 |
DarylM | right *way* | 15:15 |
DarylM | When porting things, you are pretty stuck. | 15:15 |
pboro | yeah | 15:16 |
DarylM | I had that experience porting Bugzilla to Ingres a number of years ago. | 15:16 |
pboro | haha | 15:16 |
DarylM | (Actually I had that experience porting C code 30 years ago, but that is another story from a galaxy far, far away) | 15:16 |
*** Guest30760 has quit IRC | 15:19 | |
*** Mud has joined #ingres | 15:26 | |
*** Mud is now known as Guest57321 | 15:26 | |
pboro | oops, not a good idea to load a 43 MB SQL file in isql... | 15:27 |
DarylM | 43MB file >>containing<< sql statements? !!!! yikes | 15:29 |
pboro | yup | 15:29 |
pboro | I did not want to add \p\g to the SQL file... | 15:29 |
DarylM | sed works wonders..... | 15:29 |
pboro | or just echo '\p\g' >> file | 15:30 |
DarylM | I'm wondering if the terminal monitor can eat a file that big with one \g | 15:30 |
DarylM | Sounds like a MySQL export with a crapton of insert statements terminated by semicolon | 15:31 |
pboro | val1;val2 type rows from SAP | 15:31 |
DarylM | ugh | 15:32 |
pboro | it worked fine \o/ | 15:32 |
DarylM | **cheer** Ingres | 15:32 |
pboro | by the way do you know a way to do COPY from a table in ingres so that the resulting ascii copy does not have it's fields padded to the length of the db table? | 15:34 |
pboro | for example: | 15:34 |
pboro | STR1 ;STR2;STR3 ; | 15:34 |
DarylM | fieldname=text(0)tab or its variations | 15:34 |
pboro | and I would like to have: | 15:34 |
pboro | ah, text(0), have to check that from manual, thanks | 15:35 |
DarylM | That is the syntax I have used for a long time. There are other bits of syntax that do the same thing so you might see other examples that look different but do the same thing | 15:35 |
* Vroomfondle is looking at ingstop, and is confused | 15:36 | |
pboro | hmm... from which version is it supported? page http://docs.ingres.com/ingres/9.2/sql-reference-guide/2099-storage-format-for-copy does not mention it | 15:36 |
DarylM | you should be. ingstop is an abomination | 15:36 |
Vroomfondle | it looks like it's doing a "set server shut" in iimonitor even if you give it -force | 15:36 |
Vroomfondle | but "set server shut" does not seem to actually force anything | 15:37 |
pboro | maybe iimonitor doesn't know about forcing at all... | 15:37 |
Vroomfondle | "server stop" seems to be the way to force the server to shut down | 15:37 |
DarylM | stop server | 15:37 |
Vroomfondle | yeah, that | 15:37 |
Vroomfondle | so... does this mean -force doesn't actually force the DBMS servers to shut down? | 15:37 |
Vroomfondle | that would seem like too big a bug to have been missed all these years | 15:38 |
Vroomfondle | (unless it's been fixed in 10.0 or something I guess) | 15:38 |
DarylM | It does, but there are so many scenarios where it fails to do so that it turns out not to be a particularly useful option. | 15:38 |
DarylM | And yes, the ingstop issue has been a problem forever. | 15:38 |
Vroomfondle | this really is the devil's own shell-script. I'm impressed. | 15:38 |
Vroomfondle | I bet the guy who wrote this had a *huge* beard | 15:39 |
DarylM | LOL | 15:41 |
pboro | :D | 15:41 |
DarylM | The biggest problem with ingstop, architecturally, is that its timeout handling is poor or non-existent. | 15:42 |
DarylM | So it will block on just about anything. | 15:42 |
DarylM | This is a particular problem for new dbas if the system is actually hung from a bug or similar. | 15:43 |
pboro | Why not make a C program which would run as the master of all child processes? Shell script is utterly helpless... | 15:43 |
DarylM | Ingres is more of a federation of processes. | 15:44 |
Vroomfondle | I note that if I were to alter config.dat and change the name of the server in various config lines, it'd entirely fail to work because it relies grep-ing config.dat | 15:48 |
Vroomfondle | and it figures out what it's meant to be shutting down by using various combinations of ps, csreport, awk, cut, tr and sed. What fun! | 15:49 |
pboro | You are expected to know the configuration for the years to come in one run ;) | 15:49 |
*** atrofast has joined #ingres | 15:49 | |
Vroomfondle | so does "stop server" in iimonitor shut it down cleanly (but forcibly)? | 15:55 |
Vroomfondle | or could it leave the database inconsistent like -kill can? | 15:56 |
DarylM | Stop server is clean shutdown | 16:17 |
Vroomfondle | that does seem to be a bit more reliable | 16:22 |
Vroomfondle | as in it does actually stop the server... | 16:22 |
*** KermitTheFragger has joined #ingres | 16:27 | |
*** KermitTheFragger has quit IRC | 18:31 | |
*** Guest57321 has quit IRC | 19:21 | |
*** Mud has joined #ingres | 19:26 | |
*** Mud is now known as Guest84884 | 19:26 | |
*** bonsaikitten has quit IRC | 19:53 | |
*** bonsaikitten has joined #ingres | 19:53 | |
*** Guest84884 is now known as Mud | 21:38 | |
*** DerMeister has joined #ingres | 21:58 | |
*** Mud has quit IRC | 22:09 | |
*** DerMeister has quit IRC | 23:08 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!