HandlerSocket-Plugin-for-MySQL
HandlerSocket-Plugin-for-MySQL copied to clipboard
Handlersocket off by one error in IN() requests
(Originally mistakenly posted at https://bugs.launchpad.net/percona-server/+bug/906978 )
Using Percona server 5.5.13-rel20.4-138.lenny with the included Handlersocket plugin and the following config:
handlersocket_verbose = 10 handlersocket_address = '192.168.0.1' handlersocket_port = 2678 handlersocket_threads = 16 # 2xcpu... 3 x spins wildly out of control handlersocket_threads_wr = 1 handlersocket_timeout = 30 handlersocket_backlog = 32768
defaults, 262144 is 256k
handlersocket_sndbuf = 0 handlersocket_rcvbuf = 0
Set to non 0 if connection pooling/persistent connections are used
handlersocket_accept_balance = 0 handlersocket_wrlock_timeout = 6
There seems to be an odd off by one error when using the IN() syntax (which otherwise seems to work): "2 > 1 0 5 0 @ 0 4 10 20 30 40"
[Index Id 2 / PRIMARY(id) > 0 / limit 0,5 / id IN(10,20,30,40)]
As an example, the result set here would be user id and user name:
11 / usera, 21 / userb, 31 / userc, 41 / userd
So, it's actually returning the next ID for each in the set (the usernames are correct for the returned 11/21/31/41 ids) rather then the requested IDs. I've been manually fixing this by iterating over my request and decrementing each ID in the IN() section by one.
The second part of this is when using a FILTER argument. The off by one error also seems to show up in the other direction (so I iterate over and increment instead of decrement each element)
If you need any further info or debugging, please let me know. Thanks!
Ergh, sorry about the markup on my comments. Didn't expect that
I think the current behavior of IN is weird and need to be refined. I'll revert the pull request #56 once.
Excuse me, is there any ETA on this?
@ahiguti how about 'normal' IN() implementation?