Форум пользователей MySQL

Видимо, это все-таки ошибка, т.к. при обычных инсертах Вы получите нормальное
уведомление.

Увеличьте размер указателя в таблице и напишите отчет в bugtracker.

Вероято, он ждет, пока освободится место в таблице и тогда вставит запись.

rgbeast написал:

Вероято, он ждет, пока освободится место в таблице и тогда вставит запись.

Да, ждет. Но не факт, что когда-либо дождется. DDL его точно убьет. Единственный способ - убить
строчки из таблицы.

rgbeast написал:

Значит может и дождаться. Какой иначе смысл в ограничении числа строк. Только такой, что больше их быть не должно в таблице и юзер за это отвечает. Вот он и ждет пока юзер за это ответит. Аналог - кончилось место на диске, запись нового файла вправе ждать. Так что, бага или нет - их право решать, другое дело, что в мануале не совсем этот случай описан.

от чего тогда ж не ждет при обычном INSERT? DELAYED я так понимаю это не ожидание освобождение места, а ожидание когда наберется подходящее количество записей для реального INSERTа, а если места нет на диске почему бы этим запросам не работать одинаково?

Golova написал:

DELAYED я так понимаю это не ожидание освобождение места, а ожидание когда наберется подходящее количество записей для реального INSERTа, а если места нет на диске почему бы этим запросам не работать одинаково?

Опция DELAYED указывает серверу, что следует выполнить запрос только когда соответствующая таблица осовбодится, т.е. к ней не будет никаких  запросов, ни на чтение, ни на запись (причем если во время выполнения запроса с опцией DELAYED приходят некие другие запросы, то DELAYED-запрос приостанавливается до тех пор, пока таблица не освободится вновь).

Когда DELAYED-запрос ждет, его содержимое хранится в памяти сервера, а клиент освобождается тут же (в отличие от LOW_PRIORITY-запроса, когда клиент ждет), поэтому никакой ошибки в клиенте не возникает.
Когда таблица освобождается, из памяти формируется пакет и вставляется в таблицу.
Соответственно, если таблица заполнена, вставить в нее нельзя, и содержимое так и висит в памяти, причем клиентская сторона об этом не знает, т.к. получила от сервера "ок".

Мне кажется, что не баг, а недочет в механизме работы сервера (поэтому баг и закрыли).

немного не адекватные люди там у них в суппорте... сначала вообще не поняла что предлагается, а потом влепила стандартную фразу:
"INSERT DELAYED returns no error by design.
This is documented and you have to change
logic of the application if you want to get error."

мне что перед каждым таким DELAYED INSERT вызывать:
SHOW TABLE STATUS LIKE 'f';
вычислять результат (Data_length: 327675, Max_data_length: 327679,  Avg_row_length: 5) самому высчитывая не превысят ли данные максимального размера?
или это дурдом или есть иной способ?
можно конечно поставить размер 256TB и не париться.....

Отредактированно Golova (27.06.2007 14:33:51)

Нет, просто не используйте DELAYED. Нужен низкий приоритет - INSERT LOW_PRIORITY.

Эта штука действительно асинхронная. Проверил ее в случае уникального ключа - она
тоже тихо проходит. Прийдется переписать приложение

DELAYED значит запрос будет как будто выполнен и управление вернется к скрипту. Сам запрос будет отложен в долгий ящик и может быть выполнится скоро, может быть нескоро, а может быть никогда. DELAYED не нужно использовать никогда.

LOW_PRIORITY - значит запрос будет уступать запросам на выборку, но пока он не выполнится, управление скрипту не вернется. Это дает возможность отследить ошибку, если она возникнет (например, таймаут).