After checking the "Show grant tab for this node type" checkbox for a content-type and clicking "Save Grants" I get

Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 1982 bytes) in /home2/***/public_html/includes/database.mysql.inc on line 382

Warning: Table 'system' was not locked with LOCK TABLES query: SELECT * FROM system WHERE type = 'theme' in /home2/***/public_html/includes/database.mysql.inc on line 174

Warning: Table 'watchdog' was not locked with LOCK TABLES query: INSERT INTO watchdog (uid, type, message, severity, link, location, referer, hostname, timestamp) VALUES (1, 'php', '<em>Table &amp;#039;sessions&amp;#039; was not locked with LOCK TABLES\nquery: SELECT sid FROM sessions WHERE sid = &amp;#039;7b9864c5fdc5d8ca87ccbfdc36c4c14f&amp;#039;</em> in <em>/home2/***/public_html/includes/database.mysql.inc</em> on line <em>174</em>.', 2, '', 'http://***/***/admin/user/nodeaccess', 'http://***/***/admin/user/nodeaccess', '86.159.114.87', 1233567844) in /home2/***/public_html/includes/database.mysql.inc on line 174

If I go back and try to undo it, I get

Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 40 bytes) in /home2/***/public_html/sites/all/modules/cck/content.module on line 761

I'm assuming that Nodeaccess has to update each node individually, and that this is an issue for site with a very large number of nodes (such as ours).

Comments

oldrobb’s picture

oldrobb commented

Before I tried to add this content type, I had around 40 rows in the nodeaccess table.

There are around 50,000 nodes of this content type.

Looking at the nodeaccess table it now has 20,000 rows which suggests that it has added the Grant tab to some nodes and not to others.

Can I just empty nodeaccess and start again? Or will that cause other problems?

Better still can I safely do something like delete from nodeaccess where nid > 120 (each of the nodes that was there previously had an nid below 1230, whereas each node of this content type has a much higher nid).

Alternatively, if I uninstall and reinstall this module, will it simply drop the table and allow me to start again, or will it have to make thousands of individual updates (causing another memory outage)?

Thanks.

Edit: Despite the second error I got above, I do seem to only have 42 records again - without having to execute that SQL. So hopefully it's OK. However, I get a similar message if I simply try to disable the module...

asb’s picture

asb commented

Hi robbm,

I'm experiencing similar problems; setting access permissions does not finish, nodes are rendered inaccessible for anonymous users, nodes promoted to the front page date back erratically to 2008 or even 2006; for me, neither disabling nor uninstalling or deleting the module's tables manually fixes the site back to a usable state.

However, I'm not getting an "Out of memory" error or a WSOD; after reading your issue, I experimented a bit and raised the PHP memory limit from 128M to 150M, then to 256M and lastly to insane 512M. With that much available memory the module behaves a bit different; at least "Nodeaccess" can now be disabled and uninstalled, but uninstalling does neither reset the prior access permissions, nor does it delete the nodeaccess tables in the database. IMHO, this is a very dangerous and pretty broken module, at least in rev. 5.x-1.2.

Have you managed to fix your site? Have you figured out what tables one can safely delete?

Thanks & greetings, -asb

Anonymous’s picture

Anonymous (not verified) commented
Status: Active » Postponed

Unfortunately in drupal 5.x there isn't much that can be done about this, short of raising your server memory limits. 6.x implements a batch mode that kind of gets around this, but it's not available in 5.x. Further, there isn't much this module can do about it, the actual rebuilding of access entries is handled by drupal core, where it loads every single node in the system and doesn't really release them. If you have a lot of nodes, this will suck up memory. Since it's all happening outside of this module however, there's no much I can do about this.

Anonymous’s picture

Anonymous (not verified) commented
Status: Postponed » Closed (won't fix)
oldrobb’s picture

oldrobb commented

I understand the problem. However, it can leave things in a bit of a mess...

I added a new content type last night, with only about 20 nodes. Then tried to enable the grant tab (and set the default permissions) for this content type. I figured that since there was only 20 nodes of this content type it would be OK. However, since ti tries to load all nodes, it failed. That in itself wouldn't be a big problem.

However, I'm now getting Access Denied for around 120,000 nodes. I now need to rebuild the perrmissions of each of these nodes individually. Although I have a script to do this, it's going to take a little while...

So, while I understand the limitation in Drupal 5, I wondered if it could be made to fail more cleanly?