Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

INSERT INTO ci_sessions - Query error: Duplicate entry for key 'PRIMARY' #4923

Closed
BrandonNoad opened this issue Nov 28, 2016 · 9 comments
Closed
Labels
Milestone

Comments

@BrandonNoad
Copy link

Hi,

When writing session data, every so often I get a "Duplicate entry" error. I am using the database driver with MySQL.

I was finally able to figure out reproduction steps. Basically, if the session read fails to obtain the lock (e.g the timeout limit is reached)...

if ($this->_get_lock($session_id) !== FALSE) { ... }

Then $this->_session_id is not set, which is needed by write() to detect session_regenerate_id() calls.

Then, during the write, this runs:

// Was the ID regenerated?
if ($session_id !== $this->_session_id)
{
	if ( ! $this->_release_lock() OR ! $this->_get_lock($session_id))
	{
		return $this->_fail();
	}

	$this->_row_exists = FALSE;
	$this->_session_id = $session_id;
}

If the lock is obtained here, then the write doesn't fail, but instead tries to update the session_id (not shown), resulting in the duplicate entry.

Perhaps, if $this->_get_lock($session_id) === FALSE in the read, then it should cause a failure?

narfbg added a commit that referenced this issue Nov 29, 2016
@narfbg
Copy link
Contributor

narfbg commented Nov 29, 2016

You've done great with tracking this one down, thanks!

@narfbg narfbg closed this as completed Nov 29, 2016
@narfbg narfbg added the Bug label Nov 29, 2016
@narfbg narfbg added this to the 3.1.3 milestone Nov 29, 2016
@amerloc
Copy link

amerloc commented Jan 18, 2017

this problem still exists. You marked it closed but didn't add the fix

@BrandonNoad
Copy link
Author

I'm pretty sure it was fixed in this commit: 6276926

And shipped with v3.1.3.

@narfbg
Copy link
Contributor

narfbg commented Jan 18, 2017

It was.

Something tells me @amerloc has only read the title and has a different problem solvable via RTFM. :)

@amerloc
Copy link

amerloc commented Jan 23, 2017

No I tried to upgrade one site and it completely broke. Couldn't sign in anymore. when I reverted to my old system file then I was able to login again. Just a note, I was updating from 3.0.6 to 3.1.3. I have managed to get rid of the problem by trace and error lolz

@narfbg
Copy link
Contributor

narfbg commented Jan 24, 2017

Well then, what problem did you find?

@yeongwei
Copy link

Hi @narfbg,

We are currently running with CI 3.1.6. While the problem did not present with any desktop browsers. We are using the CI Session with MYSQL database.

However, it is very consistent with Google Chrome Mobile (Version 64.0.3282.137). We even tested by removing all the active session entries from MYSQL and use the Google Chrome Mobile to serve the site. Every time we do get the same error as reported in this issue.

We tried Firefox Mobile (Version 58.0.2) but the problem did not present.

Any idea?

Thanks!

@narfbg
Copy link
Contributor

narfbg commented Feb 17, 2018

This bug happenned to trigger the same error message from MySQL that you may be getting, but it did so in a very unique way that is otherwise impossible.
It is 100% not connected to the issue you have and already fixed, so how can you possibly think it is connected?

When MySQL complains about a duplicate primary key in the sessions table, it can only be because of sess_match_ip. Read this manual page carefully, specifically the section about creating the primary key and the sess_match_ip setting.

Also, this is a bug tracker and we don't answer support questions here. When you need help, please post on our forums.

I am writing this comment only because of the uniquely weird way in which the triggered error messages happen to match, but will otherwise refuse to answer anybody's questions here because it is simply counter-productive - I can't be an assistant to everybody. On the forums, at the very least you can get help from other people who've encountered the issue or can figure it out, and I only have to chip-in on particularly hard problems or where I suspect a legitimate bug - a win-win for everybody.

@yeongwei
Copy link

Hi @narfbg, Points taken. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants