GS
Yaroslav Schekin
Вот именно. А для обсуждаемых ситуаций default policy — это retry.
Ну нет же, с чего вы решили, что default policy для дедлока - это ретрай?))
Size: a a a
2020 May 18
YS
Ну нет же, с чего вы решили, что default policy для дедлока - это ретрай?))
Хмм... с того, что это основы работы с СУБД?
Вы чего хотите — чтобы я Вам поцитировал ISO SQL или учебники, я не понимаю? ;)
Вы чего хотите — чтобы я Вам поцитировал ISO SQL или учебники, я не понимаю? ;)
GS
Yaroslav Schekin
Хмм... с того, что это основы работы с СУБД?
Вы чего хотите — чтобы я Вам поцитировал ISO SQL или учебники, я не понимаю? ;)
Вы чего хотите — чтобы я Вам поцитировал ISO SQL или учебники, я не понимаю? ;)
В общем мой поинт такой - единственный default policy - думать головой в конкретном случае. То, что база даёт информацию, о том какой это тип ошибки - нужно использовать для того, чтобы выбрать, как настроить policy в своём случае.
В распределённых системах, это наверняка не будет infinite retry on app level.
В распределённых системах, это наверняка не будет infinite retry on app level.
GS
Yaroslav Schekin
Т.е. систематически допускаете в приложениях одну и ту же ошибку (это примерно то же самое, что не обрабатывать исключения и т.п.) — IMHNSO, плохой подход (и низкокачественный код, соответственно).
> Сижу в read commited, все локами разруливаю
Кстати, в RC теперь тоже могут быть serialization failures в крайне редких случаях (при партционировании), судя по документации. ;) И "локами разруливаю" — это "простые" транзакции, скорее всего.
> Сижу в read commited, все локами разруливаю
Кстати, в RC теперь тоже могут быть serialization failures в крайне редких случаях (при партционировании), судя по документации. ;) И "локами разруливаю" — это "простые" транзакции, скорее всего.
Не могу найти про Serialization Failure в доках для RC. Вы меня заинтриговали :)
VY
дэдлоки не надо ретраить. надо анализировать причны возникновения и упорядочивать запросы в транзакциях так, чтобы больше дедлоков не было.
YS
В общем мой поинт такой - единственный default policy - думать головой в конкретном случае. То, что база даёт информацию, о том какой это тип ошибки - нужно использовать для того, чтобы выбрать, как настроить policy в своём случае.
В распределённых системах, это наверняка не будет infinite retry on app level.
В распределённых системах, это наверняка не будет infinite retry on app level.
"Эй, для этого и существуют правила. Чтобы ты хорошенько подумал, прежде чем их нарушить." ©
И то, что в каких-то случаях это стоит делать, не значит, что правил не существует.
И то, что в каких-то случаях это стоит делать, не значит, что правил не существует.
YS
дэдлоки не надо ретраить. надо анализировать причны возникновения и упорядочивать запросы в транзакциях так, чтобы больше дедлоков не было.
По умолчанию — надо.
А вот чего не стоит делать — так это "декларировать" (особенно вещи, противоречащие учебникам), не приводя аргументов.
А вот чего не стоит делать — так это "декларировать" (особенно вещи, противоречащие учебникам), не приводя аргументов.
VY
Yaroslav Schekin
По умолчанию — надо.
А вот чего не стоит делать — так это "декларировать" (особенно вещи, противоречащие учебникам), не приводя аргументов.
А вот чего не стоит делать — так это "декларировать" (особенно вещи, противоречащие учебникам), не приводя аргументов.
это ответ на мой комментарий?
YS
Не могу найти про Serialization Failure в доках для RC. Вы меня заинтриговали :)
https://www.postgresql.org/docs/current/sql-update.html
Насколько я помню, это относится и к RC.
There is a possibility that a concurrent UPDATE or DELETE on the row being moved will get a serialization failure error. Suppose session 1 is performing an UPDATE on a partition key, and meanwhile a concurrent session 2 for which this row is visible performs an UPDATE or DELETE operation on this row. In such case, session 2's UPDATE or DELETE will detect the row movement and raise a serialization failure error (which always returns with an SQLSTATE code '40001'). Applications may wish to retry the transaction if this occurs. In the usual case where the table is not partitioned, or where there is no row movement, session 2 would have identified the newly updated row and carried out the UPDATE/DELETE on this new row version.
Насколько я помню, это относится и к RC.
YS
это ответ на мой комментарий?
Да.
VY
Yaroslav Schekin
Да.
какие учебники имеются в виду? если мы говорим об аргументах
GS
Yaroslav Schekin
https://www.postgresql.org/docs/current/sql-update.html
Насколько я помню, это относится и к RC.
There is a possibility that a concurrent UPDATE or DELETE on the row being moved will get a serialization failure error. Suppose session 1 is performing an UPDATE on a partition key, and meanwhile a concurrent session 2 for which this row is visible performs an UPDATE or DELETE operation on this row. In such case, session 2's UPDATE or DELETE will detect the row movement and raise a serialization failure error (which always returns with an SQLSTATE code '40001'). Applications may wish to retry the transaction if this occurs. In the usual case where the table is not partitioned, or where there is no row movement, session 2 would have identified the newly updated row and carried out the UPDATE/DELETE on this new row version.
Насколько я помню, это относится и к RC.
Спасибо 👍
YS
какие учебники имеются в виду? если мы говорим об аргументах
По основам СУБД (да и вообще transaction processing), конечно. По идее, в каждом фундаментальном учебнике это должно разбираться.
Я плохо запоминаю конкретные источники, извините. :(
Я плохо запоминаю конкретные источники, извините. :(
MD
Yaroslav Schekin
Это всё равно, что "если [почти никогда] нет ошибок, нет смысла обрабатывать исключения" — низкокачественный код.
Этот подход — это трата какого-то количества времени совершенно впустую — на "разруливание", которое вообще никак не относится к решаемым бизнес-задачам, IMNSHO.
И да, я видел немало случаев, когда он "работает" до тех пор, пока нагрузка на самом деле — низкоконкурентная, а как только это почему-то становится не так (какой-то пик, или "естественный" рост) — сразу начинаются проблемы в данных. :(
Этот подход — это трата какого-то количества времени совершенно впустую — на "разруливание", которое вообще никак не относится к решаемым бизнес-задачам, IMNSHO.
И да, я видел немало случаев, когда он "работает" до тех пор, пока нагрузка на самом деле — низкоконкурентная, а как только это почему-то становится не так (какой-то пик, или "естественный" рост) — сразу начинаются проблемы в данных. :(
Ваше мнение не единственно правильное. У нас все работает на большом проекте, и несуществующие проблемы не станем решать, есть более актуальные
VY
Yaroslav Schekin
По основам СУБД (да и вообще transaction processing), конечно. По идее, в каждом фундаментальном учебнике это должно разбираться.
Я плохо запоминаю конкретные источники, извините. :(
Я плохо запоминаю конкретные источники, извините. :(
жаль, я хотел увидеть хотя бы название. может в моей библиотеке есть такая книжка, поискал бы
VY
моя “декларация” (хотя это просто мнение, основанное на опыте) основана на том, что меня (как ДБА) напрягают ошибке в логе.
ваша рекомендация ретраить “закрывает” этот кейс с точки зрения разработчика — всё же работает, чего эти админы опять придираются?
в результате копится технический долг на проекте.
я предпочитаю сразу обозначить проблему и то, как её следует устранять, а не прикрывать.
тоже самое рекомендую всем клиентам — анализировать транзакции вошедшие в дедлок, и предлагаю помощь в поиске оных.
ваша рекомендация ретраить “закрывает” этот кейс с точки зрения разработчика — всё же работает, чего эти админы опять придираются?
в результате копится технический долг на проекте.
я предпочитаю сразу обозначить проблему и то, как её следует устранять, а не прикрывать.
тоже самое рекомендую всем клиентам — анализировать транзакции вошедшие в дедлок, и предлагаю помощь в поиске оных.
YS
Memory Doctor
Ваше мнение не единственно правильное. У нас все работает на большом проекте, и несуществующие проблемы не станем решать, есть более актуальные
Хмм... почему Вы думаете, что это вопрос мнения? ;)
По существу приведённых аргументов Вы что думаете?
> У нас все работает на большом проекте
И вот такое я неоднократно видел, да. И написал, что также видел, к чему это приводило, вот и всё.
И мой опыт в этом отношении — не уникален, рассказывают и более "грустные" истории, чем те, с которыми я сталкивался.
По существу приведённых аргументов Вы что думаете?
> У нас все работает на большом проекте
И вот такое я неоднократно видел, да. И написал, что также видел, к чему это приводило, вот и всё.
И мой опыт в этом отношении — не уникален, рассказывают и более "грустные" истории, чем те, с которыми я сталкивался.
MD
Yaroslav Schekin
Хмм... почему Вы думаете, что это вопрос мнения? ;)
По существу приведённых аргументов Вы что думаете?
> У нас все работает на большом проекте
И вот такое я неоднократно видел, да. И написал, что также видел, к чему это приводило, вот и всё.
И мой опыт в этом отношении — не уникален, рассказывают и более "грустные" истории, чем те, с которыми я сталкивался.
По существу приведённых аргументов Вы что думаете?
> У нас все работает на большом проекте
И вот такое я неоднократно видел, да. И написал, что также видел, к чему это приводило, вот и всё.
И мой опыт в этом отношении — не уникален, рассказывают и более "грустные" истории, чем те, с которыми я сталкивался.
Потому что советуете мне как обрабатывать ошибки. Я же сказал - ошибки мониторим и их нет. Проектируется все сразу с локами. Если не записали - нам не страшно
MD
Но этих незаписей может быть пара запросов в месяц
MD
А например ошибок в коде приложения - сотни