Large error_log references database table which does not exist

  • Resolved mulgar

    (@mulgar)


    11 years, 6 months ago

    My error_log has grown excessively and is filled with one kind of error repeated over and over. An example is below:

    [27-May-2013 13:42:46 UTC] WordPress database error Table ‘[redacted].qlow_termmeta’ doesn’t exist for query SELECT term_id, meta_key, meta_value FROM qlow_termmeta WHERE term_id IN (11) made by require(‘wp-blog-header.php’), wp, WP->main, WP->query_posts, WP_Query->query, WP_Query->get_posts, apply_filters_ref_array, call_user_func_array, CTXPS_Security::filter_loops, CTXPS_Security::get_post_protection, CTXPS_Queries::check_section_protection, CTXPS_Queries::check_post_term_protection, get_metadata, update_meta_cache

    The error is not always exactly the same, but the first half (before the “doesn’t exist for query”) is always the same, but the query causing the issue on the table is not always the same. The above error is pasted from error_log except I have removed the name of the database and replaced it with “[redacted]”.

    Obviously the complaint is the table “qlow_termmeta” doesn’t exist. I checked the database and confirmed this table does not exist. Is this termmeta table supposed to exist for a default WordPress install? I don’t think so because I could not find it mentioned in https://codex.www.ads-software.com/Database_Description.

    So the next question is if it is not supposed to exist by default, then is it part of some plugin or something? I am not sure how to answer this. I’m kind of stuck working out what exactly is making reference to this table which does not exist, if it is default install or a plugin misbehaving (and if so which one so I can remove it or fix it)?

    Any guidance to help me progress on troubleshooting this issue would be greatly appreciated. Just let me know if any further information is required. Thank you.

Viewing 6 replies - 1 through 6 (of 6 total)

  • Did you ever use this plugin?
    https://www.ads-software.com/plugins/contexture-page-security/

    It seems like it might create a database table similar to what you are describing.

    I might check my cron jobs also.. and see if there was anything added there which is calling the “broken” database table.

    Thread Starter mulgar

    (@mulgar)

    Thank you so much for your response and lead Josh!

    Yes you are on to something. I do have Contexture Page Security plugin enabled, so this is most likely part of the problem. It’s kind of weird that I haven’t noticed any functionality issues yet.

    Let me look further into this plugin and see if I can pinpoint this, maybe I can reinstall it or something to get the table back.

    There ya go ??

    Plus, that plugin is only rated up to WP version 3.4.2. WP made some major adjustments in version 3.5… and it forced a lot of developers to have to restructure their plugins and themes.

    It’s possible the plugin might be “incompatible” with the most recent version of WP (3.5.1).

    Thread Starter mulgar

    (@mulgar)

    Oh ok, thanks for the feedback. I think I’ve fixed the problem in the mean time.

    I actually don’t leverage that plugin for too many pages, or users, so I just recorded the configuration manually, deleted the plugin, reinstalled, and then reconfigured the respective pages and users.

    From what you are saying, I’m guessing maybe the termmeta table got lost in the upgrade to 3.5 somehow (not sure) and maybe that’s where the problem came about, or maybe it never truly installed properly in the first place and I just never noticed any issues.

    This was only brought to my attention because my provider pinged me on disk usage with the error_log growing large.

    I checked and there is now a termmeta table created, so I assume the errors will stop. It looks like the errors in error_log have already stopped.

    From what you are saying (and since I don’t rely on this plugin too much anyway) I might look for other options or see if I can remove the plugin altogether if I don’t need it and it isn’t compatible.

    The only thing I need to do to close the loop on this is check if I can restrict the growth of error_log (which grew to an unreasonable 1.7GB).

    I really appreciate your response here so I could get to the bottom of this, thank you very much for your help!!!

    (which grew to an unreasonable 1.7GB)

    Holy Moly!! Yeah.. that’s pretty incredible!!

    My pleasure. Yeah, it sounds like you have addressed it properly. Just keep an eye on that error log for a few days.

    Take care!!

    Thread Starter mulgar

    (@mulgar)

    Yeah, I think I’ve learnt a lesson to regularly check the error_log now for any misbahaviour ??

Viewing 6 replies - 1 through 6 (of 6 total)
  • The topic ‘Large error_log references database table which does not exist’ is closed to new replies.