Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Wherever you want to put this, it cleans up the masquerade table when people don't use the switch back link.
/**
* Implementation of hook_cron()
*
* Cleanup masquerade records where people didn't use the switch back link
* that would have cleanly removed the user switch record.
*/
function masquerade_cron() {
db_query('DELETE FROM {masquerade} WHERE sid NOT IN (SELECT sid FROM {sessions})');
}
Comment | File | Size | Author |
---|---|---|---|
#13 | masquerade_module_postgresql_cron_fix.patch | 813 bytes | PMunn |
Comments
Comment #1
deekayen CreditAttribution: deekayen commentedComment #2
deekayen CreditAttribution: deekayen commentedComment #3
Junyor CreditAttribution: Junyor commentedThis change will not work on MySQL 4.0, as it doesn't support sub-queries. Since Drupal 5 still supports MySQL 4.0, it would be good if this module did, too.
Comment #4
deekayen CreditAttribution: deekayen commentedComment #5
deekayen CreditAttribution: deekayen commentednew query:
Comment #6
Junyor CreditAttribution: Junyor commentedStill doesn't work in MySQL 4.0 in 5.x-1.2. According to http://dev.mysql.com/doc/refman/4.1/en/delete.html, MySQL 4.0 and 4.1 use different syntax when table aliases are involved. It'd probably be better to not use aliases at all:
DELETE masquerade FROM masquerade LEFT JOIN sessions AS s ON masquerade.sid = s.sid WHERE s.sid IS NULL;
Comment #7
deekayen CreditAttribution: deekayen commentedThen the things that need to be bracketed look like this?
Comment #8
Junyor CreditAttribution: Junyor commentedNevermind, the problem I'm having is unrelated to this.
Comment #9
deekayen CreditAttribution: deekayen commentedIt doesn't hurt anything to make it more compatible, I just didn't realize 4.0 was different than 4.1 on this. I'll commit the following shortly:
Comment #10
Junyor CreditAttribution: Junyor commentedOK. The problem I ran into after upgrading is described in #285472: Parse error with PHP 4.
Now that I've fixed it, I do get the following error when running cron, though:
user warning: Not unique table/alias: 'm' query: DELETE m FROM masquerade AS m LEFT JOIN sessions AS s ON m.sid = s.sid WHERE s.sid IS NULL in /var/home/team/volunteers/public_html/includes/database.mysql.inc on line 172.
Your latest suggested query seems to fix it.
Comment #11
Anonymous (not verified) CreditAttribution: Anonymous commentedAutomatically closed -- issue fixed for two weeks with no activity.
Comment #12
jaydub CreditAttribution: jaydub commentedUnfortunately the solution that was used here does not work
in PostgreSQL as the syntax for DELETE with joins is also
different than that of MySQL.
The best solution for portability is to use subqueries as was
suggested. It's true that Drupal 5 still supports MySQL 4.0
and lower which do not have subqueries but Drupal 6 requires
MySQL 4.1 which does support subqueries.
So any chance the query can be reverted to use subqueries
in the Drupal 6 version of masquerade so that PostgreSQL
users and MySQL users both run w/o error?
Comment #13
PMunn CreditAttribution: PMunn commentedYep my PostgreSQL system is banging its head against this error every time Cron runs. Annoying. My fix is attached for 5.x 1.3.
Comment #14
deekayen CreditAttribution: deekayen commentedI committed #13 and reverted back to the original subquery version for #12 in 6.x.
Comment #16
deekayen CreditAttribution: deekayen commentedLooks like I oops'ed on the 6.x version.
Comment #17
cYu CreditAttribution: cYu commentedJust missing a closing paren...
should be
Comment #18
deekayen CreditAttribution: deekayen commentedWill be in Masquerade 6.x-1.1.
Comment #19
deekayen CreditAttribution: deekayen commentedComment #21
scottgifford CreditAttribution: scottgifford commentedAny chance of getting this fix in the Drupal 5 branch? I made the modification manually to my local copy of 5.x-1.3 and it works flawlessly on Postgres. It looks like the patch here will apply cleanly to 5.x-1.3.
Comment #22
deekayen CreditAttribution: deekayen commentedI'm staring at DRUPAL-5--1-3 and DRUPAL-5 and don't see a problem with the cron query. They're different than D6. What did you change?
Comment #23
scottgifford CreditAttribution: scottgifford commentedOriginal code was this:
which did not work with Postgres. I changed it to this:
and it now works properly for me.
Comment #24
deekayen CreditAttribution: deekayen commentedYeah, that's what was in the latest -dev copy. I turned it into a 5.x-1.4 release just now.
Comment #25
scottgifford CreditAttribution: scottgifford commentedThanks, I'll give it a try!
Comment #26
kevinquillen CreditAttribution: kevinquillen commentedShouldn't that query check the timestamp too instead of selecting all sid's from the sessions table? Like, you should only look back 24 hours before destroying the masquerade session, maybe less.
I am trying to pin down why PHP runs out of memory when cron runs and saw this hook.
**edit**
CAPTCHA employs this in its cron:
Seems like this would make it a lot faster if you have thousands of sessions in the sessions table. Just a thought.
Comment #27
deekayen CreditAttribution: deekayen commentedgh0st25: no, because then someone who gets their masquerade deleted because they expect their session to last 3-4 days will file a bug about disappearing masquerade states. It probably would be faster, but if you're having performance problems related to the size of your sessions table, I recommend Session Expire instead of adding arbitrary time limits to the cleanup process here. Moreover, the subquery select for IN() is entirely database - it shouldn't have any impact on your PHP's instance of memory consumption.
Comment #28
scottgifford CreditAttribution: scottgifford commentedI forgot to mention that I've been running 5.x-1.5 with Postgres for a few months now with no issues.