| |
| |
| |
|
Page: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
<Hydr0p0nX> imma try one more thing and if it doesn't work i might just be using a binary this time
<will[werk]> You're going to give up?
<will[werk]> What kind of hacker are you? Hackers don't quit!
<Hydr0p0nX> lol
<Hydr0p0nX> i'l get it working one way or another
<Hydr0p0nX> i'm trying the compile options included in INSTALL-SOURCE
<Hydr0p0nX> more than i need but if it works. ....
<brion> I've got a query that's working on 4.0 but fails with a somewhat confusing error on 5.0. Any thoughts? http://test.leuksman.com/view/MySQL_5_issues
<damog> Hello, all.
<brion> explicitly adding the table name on pl_namespace and pl_title in the ON clause doesn't seem to make any difference, it gives the same error about unknown column
<flupps|UK> brion: which table is those columns in?
<flupps|UK> s/is/are/
<brion> flupps|UK: in pagelinks (table definition is listed on that link)
<flupps|UK> brion: I'd do a debug print of the query
<inviso> brion: print $sql and paste that.. It's a pain to look at as is
<flupps|UK> what inviso said!
<inviso> what flupps|UK said!! :)
<brion> 1:56pm] brion: SELECT 'BrokenRedirects' AS type, p1.page_namespace AS namespace, p1.page_title AS title, pl_namespace, pl_title FROM `mw_pagelinks`, `mw_page` AS p1 LEFT JOIN `mw_page` AS p2 ON pl_namespace=p2.page_namespace AND pl_title=p2.page_title WHERE p1.page_is_redirect=1 AND pl_from=p1.page_id AND p2.page_namespace IS NULL LIMIT 50
<brion> [1:56pm] brion: ewwww
<inviso> that must have been a while ago ;o)
<damog> Is there any way I can give privileges to a user to all databases but one? I mean, grant any kind of privileges to all databases but an specific one?
<brion> in another channel :)
<ecliptik> I just noticed in my /usr/local/mysql/var/ dir there's a lot of 1gb files called hostname-bin.00000X, I'm guessing their binary log files, and say in /etc/my.cnf that I can turn them off. The question I have is can I turn them off, stop mysqld, remove the files, then start mysqld without it screwing anything up.
<flupps|UK> brion: and if you copy and paste that, you get the same error?
<zwitter> hey brion.. don't i know you from somewhere else? ;)
<flupps|UK> ecliptik: those are used for point-in-time recovery and replication, if you need neither, safe to disable.
<brion> flupps|UK: yep
<flupps|UK> damog: not with the current system, no
<inviso> brion: prefix with the table names, try again and paste the error if it differs. We don't even know which table pl_namespace is supposed to be in.
<ecliptik> flupps|UK, cool, thanks. All I really want to do is backup innoDB tables from tape if the DB machine takes a dive
<inviso> damog: no
<brion> inviso: i told you it's in pagelinks (mw_pagelinks on the particular database i pasted that sql from)
<damog> inviso, flupps|UK: Thanks.
<flupps|UK> brion: why mix comma and ansi join syntax?
<brion> flupps|UK: who knows, man. who knows. :)
<inviso> brion: Right. Tell mysql that. Pastebin the new query, the new error and show create table mw_pagelinks
<brion> inviso: that's all at the link i gave above
<brion> table definition and query
<inviso> not with the table prefix on all columns.
<inviso> let's get one that works and then figure out why yours doesn't.
<inviso> don't bother with php. Just use the command line at this point.
<brion> http://test.leuksman.com/view/MySQL_5_issues#With_prefixes
<flupps|UK> could actually be a bug
<flupps|UK> it does look correct
<flupps|UK> and something was changed in the order of execution with inner/outer joins mixed when the outer was after the inner
<will[werk]> *gasp* A BUG?
<flupps|UK> since it gave the wrong result before and actually always used the outer as a driving table
<brion> eww
<flupps|UK> (it was documented, but ugly)
<inviso> still no prefix on it pl_namespace
<brion> inviso: it's a column name
<brion> column names don't change in our table prefix system
<brion> it'll be pl_namespace no matter what the table prefix is
<flupps|UK> brion: I can reproduce it with a small test case, I can file the bug for you
<brion> flupps|UK: thanks
<inviso> brion: ok. That's fine. You're likely dealing with a bug, but not much way we can test it without a data dump or your humor.
<brion> happy to provide if wanted
<flupps|UK> inviso: I found a very easy way to reproduce it
<inviso> throw a smallish dump up and I'll test it ^H^H^H
<inviso> flupps|UK: too fast man :)
<brion> hehe
<brion> just to test the error doesn't require any data ;)
<inviso> flupps|UK: what did you end up with?
<dooder> any of you guys use jboss with mysql ?
<risk23> http://hashmysql.org/paste/viewentry.php?id=901
<risk23> should this really work this way? seems incredibly strange
<flupps|UK> brion: can you place ( ) between the FROM ( .... ) LEFT JOIN
<flupps|UK> and see if that works better
<inviso> risk23: you need a join on your first query
<SpComb> is this *the* mysql channel, btw?
<inviso> but of course :)
<brion> flupps|UK: it returns results with that
<SpComb> 286 isn't too bad at all
<SpComb> but hah! quakenet php has even more
<flupps|UK> brion: is it the results you expect?
<brion> checking :D
<inviso> SpComb: 286? Is that answers per second?
<risk23> inviso: hmm. why and how should it look? i guess i'm not sure what needs to be joined, hence not sure how it should look.
<inviso> risk23: any time you include more than one table, you're needing a join (real unlikely to want a cross product)
<SpComb> people on this channel
<inviso> !tell us about joins
<SQL> inviso asked me to tell you this: Very basic join information: http://hashmysql.org/index.php?title=Introduction_to_Joins - For more indepth info: http://dev.mysql.com/tech-resources/articles/mysql-db-design-ch5.pdf
<brion> flupps|UK: looks correct
<inviso> SpComb: yeah, I was being trite. Number of people in the channel is hardly a measure of anything. Try #gentoo
<inviso> risk23: take a look at those docs.
<SpComb> I know
<SpComb> lost of idlers
<SpComb> try #idlerpg
<SpComb> not bad at all
<flupps|UK> brion: you're welcome!
<brion> thanks for the help flupps|UK and inviso!
<flupps|UK> ;)
<risk23> inviso: i guess i better explain what i'm trying to do. i have two tables, each of which have id columns. one of the tables may have 0 rows. i need to, in one select statement, determine the maximum of the maximum id from table1 and maximum id from table2 and add 1 to that.
<risk23> i'm hoping that by embedding this into an insert and qualifying the insert with HIGH_PRIORITY, i'm going to get an atomic insert
<flupps|UK> won't that give a syntax error?
<Sembiance> :)
<inviso> risk23: incrementing is better left to auto_increment
<inviso> risk23: if it's not, you can't do it in one query because you'll have to lock and unlock tables
<risk23> inviso: it is not possible to use auto_increment in this case, unfortunately
<risk23> my understanding is that doing an INSERT HIGH_PRIORITY disables concurrent inserts
<inviso> but not between and insert and the preceding select...
<inviso> why can't you use auto_increment?
<risk23> if i do an INSERT HIGH_PRIORITY tablename (id) VALUES(SELECT(...))
<risk23> that should be atomic, no?
<inviso> erm, that I don't know.
<risk23> i would expect so, since it's a subselect within an atomic insert
<inviso> mishehu: np, enjoy
<mishehu> we weren't using hte "HAVING" so that was where we were going wrong
<inviso> risk23: I wouldn't be quite so sure, but it may be so.
<inviso> risk23: anyway, why not use auto_increment?
<risk23> inviso: for me, a very narrow race window is equivalent to atomicity
<flupps|UK> brion: http://bugs.mysql.com/bug.php?id=13832
<risk23> inviso: because i'm dealing with a legacy app, which generates its own ids
<risk23> and changing the code involved is not practical given the time constraints and the current complete fubarrment
<inviso> risk23: bah, no fun to be you :)
<risk23> i need something i can throw up tonight to alleviate the problem
<risk23> not fun
<risk23> profitable ;)
<arjenAU> risk23: use InnoDB storage engine for these tables and use the appropriate level of transaction isolation. that'll take care of your locking.
<risk23> arjen: all good advice. not possible for the same reason as stated above.
<arjenAU> which reason is that?
<inviso> ok, so you said you want the max ids from both tables and add 1 to that? add 1 to the sum of the ids or add one to each id?
<mishehu> I have to reread the current status of innodb... I recall (though maybe incorrectly) that there was something funky about innodb tables with auto_increments that might occur after mysql has been stopped and restarted...
<risk23> arjen: legacy app. innodb'ing it would kill it
<arjenAU> risk23: because? the app doesn't care.
<arjenAU> risk23: me thinks you need to get properly informed.
<risk23> arjen: the performance does. it's been tested.
<arjenAU> only if you completely stuff up your server tuning. which is a skill.
<risk23> arjen: it's a moot discussion - the conversion of the dataset would take hours
<close_to_debian> I get error when exporting db from 4.0 to 4.1. Please look in to this http://sial.org/pbot/13953?wr=on&tidy=on&hl=on&submit=Format+it%21
<arjenAU> but heck, you're intent on finding reasons to make it not work. well done. you succeeded. I won't bother giving any other suggestions.
<arjenAU> just don't blame mysql. there's quite a number of decent ways to make this work.
<risk23> arjen: i'm not blaming mysql. i'm blaming the braindead people who coded this mess which i now have to fix.
<inviso> close_to_debian: we'd need to see what's around that line to help..
<arjenAU> close_to_debian: you need to paste your entire query also. and eh, you can read the error just like anyone else, it's quite specific about where the prob is.
<risk23> arjen: i'm perfectly happy with mysql, it's perfect for this app (lots of reads, few writes, no consistency requirements, medium coherency bound requirements) if it had been properly implemented
<close_to_debian> arjenAU: http://sial.org/pbot/13954?wr=on&tidy=on&hl=on&submit=Format+it%21
<risk23> mishehu: i'll have this whole mess reimplemented in a few days. i just need a fast temporary fix.
<arjenAU> risk23: lots of writes would still be fine for mysql.
<close_to_debian> Please check
<arjenAU> close_to_debian: woof
<risk23> arjenau: it would kill my replication setup though ;)
<close_to_debian> arjenAU: I had an error with option but it was fixed when it was enclosed in ``
<arjenAU> risk23: that too is impressive.
Return to mysql
or
Go to some related
logs:
Qt "cannot find -lQtGui"
linuxhelp
chatzone
|
|