As part of my investigation on #910388: Installation fails on PostgreSQL >=8.4: Invalid escape sequence., I found this issue where a cache miss on the router item for the front page causes this SQL error, since the page has no ancestors, an empty array is passed to an IN-query, which yields this error (on PostgreSQL):

PDOException: SQLSTATE[42601]: Syntax error: 7 ERROR: syntax error at or near ")" LINE 1: SELECT * FROM menu_router WHERE path IN () ORDER BY fit DESC... ^: SELECT * FROM {menu_router} WHERE path IN () ORDER BY fit DESC LIMIT 1 OFFSET 0; Array ( ) in menu_get_item() (line 426 of includes/menu.inc)

The attached patch should fix that, and as far as I can see, not otherwise change the code behavior.

CommentFileSizeAuthor
2010-09-13-no-ancestors-SQL-error.patch572 bytesmikl

Comments

Crell’s picture

Component: database system » menu system

This isn't a DB issue as much as a menu system issue. Refiling.

chx’s picture

Status: Needs review » Postponed (maintainer needs more info)

#261148: menu_masks variable is empty (race condition) ancestors can't be empty. That's impossible. The first actual Drupal page will force-rebuild the router and set router masks. If you see this error, we need more details how did you got there. Note this issue is a staple of "I started install, it broke and I tried to restart without emptying out the database and the installer got confused". So If you can reproduce this from an empty database then I need to know how. If you can't please close the issue.

mikl’s picture

Status: Postponed (maintainer needs more info) » Needs review

Well, it happens when the menu rebuild fails for whatever reason, as in the aforelinked bug. Currently, its completely reproducible if you install Drupal 7 on a PostgreSQL server in standards mode, but that is only because #910388: Installation fails on PostgreSQL >=8.4: Invalid escape sequence. has not been fixed yet.

If this situation is otherwise impossible, feel free to discard this patch, but if it remains in the improbable realm, I’d say the empty-check I added in my patch is a healthy thing :)

David_Rothstein’s picture

alex_b’s picture

#898634: install_drupal(): call to install_display_output() results in SQL syntax error causes the same error but I am not sure whether it's for the same reason. The WHERE path IN () fatal error reported in #898634 occurs very early in the installation process.

chx’s picture

Status: Needs review » Closed (duplicate)

Reviewing the other issue, it has a lot better arguments.

kattekrab’s picture

Version: 7.x-dev » 7.0-beta2
Status: Closed (duplicate) » Active

Originally posted this here: http://drupal.org/node/898634#comment-3615514

Here is a list of tables created at that point: http://pastebin.com/qNGV0W4S

Error message
PDOException: SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ') ORDER BY fit DESC LIMIT 0, 1' at line 1: SELECT * FROM {menu_router} WHERE path IN () ORDER BY fit DESC LIMIT 0, 1; Array ( ) in menu_get_item() (line 426 of /var/www/drupal/includes/menu.inc).

This is happening against MariaDB but not against MySQL - none of the patches attached to the other issue seem to fix it.

cafuego’s picture

The exact same issue occurs on my machine with the exact same setup. Apache2 + MariaDB 5.1.42 on Ubuntu 10.04.

I've retried re-install about 10 times now (with a newly created empty DB and a newly copied settings.php each time, of course). The problem occurs with both Firefox and Chrome. I've modified my Apache configuration, but regardless of using mod_vhost_alias, the problem still occurs.

I've downgraded MariaDB to the Ubuntu-packaged MySQL 5.1.41 and that has made exactly no difference, so I guess we can stop blaming MariaDB :-)

I've also found #313606: menu_router error during install but none of the suggested fixes in that issue resolves the problem here.

I've done a successful install on a different machine using an older Ubuntu, PHP and MySQL and exported all executed queries against the new DB via mysqlbinlog, then run the resulting queries against MariaDB. That produces a complete and working Drupal installation.

chx’s picture

Status: Active » Closed (won't fix)

The other issue is where you want to be. This message is a symptom and nothing more. Under normal circumstances it can't happen. We said that already.