Такой вопрос если я начинаю делать sql запросы и потом

делаю коммит, может ли при коммите появится какая-то логическая ошибка или ошибки появятся на этапе sql запроса?

Эээ... а о какой именно СУБД речь, и что Вы имеете в виду под "логической ошибкой"?

PostgreSQL. Ошибка - хз ну например ключ null вставляется или что то подобное, вообще какие ошибки могут быть при коммите , кроме того что бд может отвалится. И еще Допустим если у меня комит, не прошел, нужно ролбэк делать?

Да много какие исключения могут быть при commit, в принципе (чаще всего — связанные с serialization failures и deferred constraints / triggers). Простой пример: https://dbfiddle.uk/?rdbms=postgres_13&fiddle=09cbb58dc3b0e75880bf463789187c78 > Допустим если у меня комит, не прошел, нужно ролбэк делать? Что такое "не прошёл"? В любом случае, от лишнего ROLLBACK проблем не будет (если он был лишним — получите warning да и всё).

Теоретически может появиться что-то из ошибок при выполнении commit, но это очень редкое явление, почти нет таких СУБД, что откладывали бы проверки целостности и правил до момента выполнения commit. Причина простая: это дорого. Однако, есть важное исключение из этого правила: при выполнении распределенных транзакций commit наоборот будет вызывать ошибки достаточно часто.

Нет, делается сам. Но есть нюансы при организации вложенных транзакций

И savepoint ...

https://oracle-base.com/articles/8i/constraint-checking-updates

В PostgreSQL это может быть чаще, чем в других, наверное — из-за особенностей реализации isolation. Да и вообще, если программист решил, что ему нужны deferrable constraints — СУБД будет это делать, дорого это или нет. ;)

У меня кстати случилась одна фигня на днях в MS SQL, я думал что в зависимости от уровня ошибки raiseerror сделает rollback сам. Короче зависла база я так понял в ожидании конца транзакции :D

Нет, raise error лишь передает ошибку клиенту

Но там уровни тип есть, где-то на stack вычитал что мол транзакцию отменит

Не с читай стэк по утрам...

Не отменит.

Обсуждался-то PostgreSQL. ;) Что касается MS SQL, это зависит от настроек сессии, вот пример: https://dbfiddle.uk/?rdbms=sqlserver_2016&fiddle=a0f3fe8b42019a2f2d02fdc2f000156a @MasterZiv — тоже см. пример выше. Более того, неиспользование XACT_ABORT — ошибка при написании хранимок, которую совершают почти все, мне кажется. :( См. http://www.sommarskog.se/error_handling/Part1.html , если что.

Мб будет шок сейчас, но это был триггер))

Нет, совсем не будет. См. статью, опять-таки.

Я писал хранимки когда ещё не было никаких xact abort, - все норм

Ммм, вот оно чё, понял принял, спасибо, буду знать)

А я видел кучи написанных без XACT_ABORT хранимок, как и последствия этого. И нет, совсем не "норм" ("нет очевидных ошибок" <> "всё нормально")! И даже на сайте, на который я давал ссылку, где-то было всё это детально описано, по версиям MS SQL (spoiler: чем дальше в прошлое, тем страшнее, в среднем).

Все решается дисциплиной кодирования

Да-да, видел я, как она "решается". Нет, если всё вот это http://www.sommarskog.se/error_handling/Part2.html заучить наизусть (это я нашёл ссылку, о которой писал выше) — может быть, но "дисциплинированные кодеры" об всём этом, скорее всего, даже не подозревают. ;)

Так все дело в силе воли!

Нет, писать нужно просто и правильно, а не заучивать всякую дурь, которая ещё и меняется от версии к версии, IMNSHO. Вот, там даже есть summary (которая подходяще называется "Throw Your Ideals Away – This is SQL Server"): http://www.sommarskog.se/error_handling/Part3.html#throwidealsaway ;)