why did they change this? I reverted everything to 5.0.19 and I'm
using load data infiles again, with zero locking issues
It has always been like that.
load data infile seems to use different logic from replace delayed,
it does not lock at all
What table type do you have in each version
matt_lists wrote:
It's not a bug. I guess this is a myisam table?
http://dev.mysql.com/doc/refman/5.1/en/table-locking.html
Any time the table is changed with myisam, the whole table is locked.
That's the way it works.
Innodb doesn't do it this way but it might cause other issues for you.
T
chris smith wrote:
On 8/23/06, matt_lists <[EMAIL PROTECTED]> wrote:
Not sure if this is a bug
we are updating a large table with replace delayed from our feeder
systems, 1000 records at a time using limit's on the input data pull
this works great when there's fast selects from the table, whi
It's not a bug. I guess this is a myisam table?
http://dev.mysql.com/doc/refman/5.1/en/table-locking.html
Any time the table is changed with myisam, the whole table is locked.
That's the way it works.
Innodb doesn't do it this way but it might cause other issues for you.
Try changing the tab
On 8/23/06, matt_lists <[EMAIL PROTECTED]> wrote:
Not sure if this is a bug
we are updating a large table with replace delayed from our feeder
systems, 1000 records at a time using limit's on the input data pull
this works great when there's fast selects from the table, while the
insert is goi
Not sure if this is a bug
we are updating a large table with replace delayed from our feeder
systems, 1000 records at a time using limit's on the input data pull
this works great when there's fast selects from the table, while the
insert is going
when a site does a large pull, which can t
