| Project: | Boost |
| Version: | 6.x-1.x-dev |
| Component: | Cron Crawler |
| Category: | bug report |
| Priority: | minor |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
Hi there,
I noticed today that I was getting many errors on one of my sites. Now why on that site and not others... I'm not too sure, but the fact is that the SHOW TABLES LIKE is MySQL specific and thus you cannot use it just like that. (See #286986: MySQL: SHOW TABLES LIKE database.tablename doesn't work for a solution)
To the minimum you'd need to make boost_get_time() return 0 if someone uses PostgreSQL. Meaning that the whole CRON feature is not available for people like me. (No big deal, if you ask me!)
So at this time I just turn off that feature and the error goes away, except in the boost_block() which may generate that error too.
By the way, I would suggest you check for installed (enabled) modules rather than the database for a table. This would be more likely to work properly in all cases.
Thank you.
Alexis
P.S. as a side note, if you do not check for "history", you may want to remove the variable from the max() call below. (line 2054 and 2061 in the Oct 24th version.)
Comments
#1
Thanks, let me know if this does it. Checking for the table makes life easy; otherwise I have to check for the module, figure out what module uses what table and then check for that table.
#2
committed
#3
Automatically closed -- issue fixed for 2 weeks with no activity.
#4
Hi Mikey,
Today, I got a large list of errors when I cleared my cache. I guess that's the first time I've done it on a large site with the "newest" version (the one where you added the _0, _1, etc. It was from 2009-Nov-18)
PostgreSQL does not have the SHOW instruction. So the SHOW <anything> won't work...
Looking at the boost.module file, I noticed that you had several:
I'll be happy to test and see that the fixes work properly.
Thank you.
Alexis
#5
Changing the title & priority since it is much less a problem than the first such problem.
#6
SHOW shows up in the documentation
http://www.postgresql.org/docs/8.4/interactive/sql-show.html
If you could do a SHOW ALL we might be able to figure out what the max packet size is for postgreSQL.
SHOW VARIABLES WHERE Variable_name = 'max_allowed_packet'
Asked in IRC and they said 2 GB was the limit... so I'm tempted to set this to 16MB for postgreSQL; too high and PHP runs out of ram. They also suggested using COPY instead of INSERT
http://wiki.postgresql.org/wiki/How_to_use_PostgreSQL%27s_COPY_function_...
http://www.postgresql.org/docs/current/static/sql-copy.html
http://www.varlena.com/GeneralBits/116.php
pipe it in instead of using a file; if going to use COPY.
#7
COPY is a good idea, it is a lot faster in part because the data to be sent is going to be smaller (only one SQL line at the start, then data, then an end of statement marker.) Now it is very specific to PostgreSQL... My PHP limit is set to 128Mb so 16Mb would work fine for me. But a lot of people have it at 16Mb by default.
I'm attaching the output of SHOW ALL under PostgreSQL 8.3.x. Wow! I did not know it existed! The syntax is SHOW <variable name>
Thank you.
Alexis
#8
And this time, the attachment! 8-)
#9
Backport some of the improvements to this idea from the core issue #512962: Optimize menu_router_build() / _menu_router_save(). BTW this patch against core helps a lot with the slow menu rebuild :)
#10
committed
#11
Automatically closed -- issue fixed for 2 weeks with no activity.