@mattab opened this Issue on June 7th 2012 Owner

Since Piwik 1.8 (tickets #2984 and log deletion #2805), we require the LOCK privilege to install Piwik. Apparently, some web hosts have disabled it and refuse to enable it.

If you experience the problem that your web host does not allow LOCK privilege on the piwik mysql user, but you would like to use Piwik, please comment in this ticket. Thank you!

@diosmosis commented on June 18th 2012 Member

(In [6483]) Fixes #3204, removed LOCK TABLES privilege check from installation. Modified LogDataPurger so log_actions are not purged if the lock tables privilege is not granted.

@diosmosis commented on June 18th 2012 Member

Committed a fix for this, but there's still one other instance of LOCK TABLES in ArchiveProcessing::loadNextIdarchive. I don't think its necessary, but I didn't write the code so I've left it for now. Is locking necessary here? If it is, I think it can be replaced w/ GET_LOCK.

@mattab commented on June 18th 2012 Owner

It is "necessary" to make sure that when several archives are requested at the same time, they have a distinct idarchive allocated. Sounds good if we can use GET_LOCK instead. Could we not use GET_LOCK for the log deletion from log_action as well btw?

Also it would be nice to say in the UI, in the inline help "The table log_action will not be purged: please grant the LOCK privilege to the %s Mysql user" so that users understand that the feature is limited pending the privilege.

@diosmosis commented on June 18th 2012 Member

Replying to matt:

It is "necessary" to make sure that when several archives are requested at the same time, they have a distinct idarchive allocated. Sounds good if we can use GET_LOCK instead. Could we not use GET_LOCK for the log deletion from log_action as well btw?

The reason I think the locking might not be necessary is that the INSERT INTO SELECT should lock the table itself. Do you know of a situation where it wouldn't?

And I don't think GET_LOCK will work for log_action purging. For log_action purging we need to make sure no visits/link_actions/conversions/etc. are added while actions are being deleted and GET_LOCK won't do that (unless you add a GET_LOCK call to the Tracker).

Also it would be nice to say in the UI, in the inline help "The table log_action will not be purged: please grant the LOCK privilege to the %s Mysql user" so that users understand that the feature is limited pending the privilege.

Ok, will get to it soon...

@mattab commented on June 19th 2012 Owner

The reason I think the locking might not be necessary is that the INSERT INTO SELECT should lock the table itself. Do you know of a situation where it wouldn't?

maybe a GET_LOCK would be enough here....? but we need the lock.
it was a patch suggested by power user lorieri which fixes an edge case bug hard to reproduce, so I'm reluctant to break it again by removing the lock :)

And I don't think GET_LOCK will work for log_action purging.
Thanks for reminding me.

@diosmosis commented on June 20th 2012 Member

(In [6485]) Refs #3204, added extra info message to privacy manager purge function when lock tables privilege is not granted to user & replaced lock tables sql in ArchiveProcessing w/ GET_LOCK.

Notes:

  • Added Piwik_GetDbLock & Piwik_ReleaseDbLock functions.
This Issue was closed on August 15th 2012
Powered by GitHub Issue Mirror