There's a race condition in sess_read which could lead to a warning being printed on a page. Read more about it at http://drupal.org/node/44947#comment-68849

This report is for tracking the race condition.

44947 has evolved to track the patches committed here. I'm filing this separately so that the two issues can be tracked separately.

Comments

chx’s picture

chx commented

INSERT IGNORE would solve this neatly. I have asked Cvbge to comment here whether it's possible in pgsql or not.

Cvbge’s picture

Cvbge commented

For postgresql the only solutions seems to be locking or @db_query(). I was thinking about pl/pgsql error trapping, but that's available since 8.0 only...

@ error operator is supposedly slow, but anyone knows how slow, and is it slow also when there is no error? The bad side of @ is that it blocks all errors, not only unique value errors

magico’s picture

magico commented

The other issue was closed. Can we close this one, or this needs further investigation?

Wesley Tanaka’s picture

Wesley Tanaka commented

The other issue evolved to become completely independent of this race condition.

robertdouglass’s picture

robertdouglass commented

I didn't understand whether that was a "Yes, we can close this issue" or a "No, Drupal and Earth are in mortal race condition danger so let's fix this dire problem" =)

Wesley Tanaka’s picture

Wesley Tanaka commented

As far as I know, the race condition is still there and Drupal and Earth are in rare race condition danger and my opinion is: let's fix this probably not life threatening problem.

magico’s picture

magico commented

@Wesley: can you do some tests with the last HEAD, to check and make a report about that race condition?

Thanks!

Wesley Tanaka’s picture

Wesley Tanaka commented
Title: race condition in sess_read » race condition in sess_write

Testing is an unreliable way to determine if a race condition exists, as you can never verify that a race condition has been fixed.

That being said, sess_read no longer appears to have the potential for writing to the database. However, the unlocked select/test/insert sequence has been moved into sess_write. The original race condition exists if and only if sess_write can be called twice or more concurrently with the same value for $key in at least 2 calls.

I don't know what exclusion PHP does when it calls session handlers set in session_set_save_handler. I doubt it does any, in which case the race still exists.

bdragon’s picture

bdragon commented
Version: x.y.z » 6.x-dev

6.x-dev session_write appears to still have this race condition.

That said, you have to be using multiple browser windows and doing multiple things at once to trigger the issue. This might

Wesley Tanaka’s picture

Wesley Tanaka commented

It also tends to show up if you include drupal generated (images, css, javascript) on a drupal generated page

hswong3i’s picture

hswong3i commented

Subscribing

klando’s picture

klando commented

Using constraint, we will avoid race condition on postgresql (others, I don't know). No need to lock explicitly all the table !

dharamgollapudi’s picture

dharamgollapudi commented

subsribing...

arhak’s picture

arhak commented

subscribing

gpk’s picture

gpk commented
Status: Active » Closed (duplicate)

Duplicate of #213699: Race condition in sess_write() causes duplicate entry error in {sessions} table. Closing this one in favour of the other since the other has patches (and the session handling code has probably changed since this issue was originally opened so not all the comments may be particularly relevant now).