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

https://github.com/ept/hermitage

dirty read у innodb mysql - сплошная проблема.
Вот кусок таблицы оттуда:
So-called isolation level Actual isolation level G0 G1a G1b G1c OTV PMP P4 G-single G2-item G2"read uncommitted" read uncommitted + — — — — — — — — —"read committed" monotonic atomic view + + + + + — — — — —"repeatable read" *? monotonic atomic view + + + + + R/O — R/O — —"serializable" serializable + + + + + + + + + +
Это вполне соответствует ISO SQL, насколько я вижу. Где проблемы-то?

ОзверинPgSQLanonymous3, учитывая, что пишется везде PostgeSQL, то я автоматом SQL убираю.
Впрочем, в официальной вики постгреса тоже пишут postge SQL...что как бе заставляет удивиться вашему замечанию( и надобности его вообще в данном контексте).
И где же это там пишут? Попробуйте:
https://wiki.postgresql.org/wiki/Special:Search?search=postge&go=Go
И вот отсюда:
https://wiki.postgresql.org/wiki/FAQ :

Postgres is a widely-used nickname for PostgreSQL. It was the original name of the project at Berkeley and is strongly preferred over other nicknames. If you find 'PostgreSQL' hard to pronounce, call it 'Postgres' instead.

Я просто намекнул, что базы данных "postgre" не существует. ;)
И, кстати, многие его разработчики почему-то неприязненно реагируют, когда слышат это слово... кто его знает, почему.

Leonid KudryavtsevС PostgreSQL и MySQL секс имел только в конце 90-х.
Сначала был выбран PostgreSQL, но он в _тот_ момент полностью не работал. Нужны были таблички в 45 000 записей + таблица связей в 2 миллиона - без vacum'а не работало, а vacum ставил клином сервер на 2 часла, что для I-net проекта было недопустимо. В общем, PostgreSQL с матерными словами пришлось выбросить на помойку, как студенческую поделку вообще не приспособленную к жизни.
Ну и правильно, он тогда слова доброго не стоил (release notes тех лет сейчас читаются как "ужастик").

Leonid KudryavtsevВ современное время, я вижу реально работающие в продакшене СУБД PostgreSQL и понимаю, что его все же допилили до работоспособного состояния. Читая доки по PostgreSQL, складывается ощущение. что по "движку" он примерно приблежается к Oracle 8i.Скорее всего, он давно его превзошёл. Впрочем, в сортах Oracle я не разбираюсь. ;)

Leonid KudryavtsevНасколько "родовые травмы" PostgreSQL (vacum и работа через ФС) критичны для нагруженных систем в продакшене - не знаю.
Почему Вы считаете это "родовыми травмами", почему верите в эту чушь?

Leonid KudryavtsevНо опасения у меня все же есть, т.к. на реальных проектах с Oracle (когда работали через ФС) я видел, когда ОС при full table scan запросе из таблички большей чем память на сервере, думала, что компьютер это файлопойка, раздувала кэшь файловой системы по максимому и все приложения отправлялись в своп. На Oracle выличилось "волшебным пендалем" админу и включением Direct IO. Что при таком патерне запросов нужно делать с PostgreSQL - я не знаю.
Что ж, распространяемый фанатами Oracle FUD о PostgreSQL на Вас подействовал, видимо.
Не зря стараются. ;( Кстати, ни разу не встречался с подобной ситуацией на современном PostgreSQL.

Leonid KudryavtsevВсе было бы хорошо, если бы хотя бы были вменяемые доки по настройке ОС + PostgreSQL.

Частично это есть в документации PostgreSQL (включая настройки OS), но и немалая часть --- в книгах.

SiemarglМаслица подолью - а еще пробегали тесты, что постресс на тех же запросах, что и оракл, генерит вдвое сетевого трафика.
А ссылки у Вас есть?

Leonid KudryavtsevЕсть подозрение, что binary поля передаются ровно так, как отображаются - т.е. как HEX строчки. Т.е. в два раза больше трафика. Снифером трафик не смотрел, но по коду JDBC похоже, что по сети идет HEX.
Так тут "виноват" драйвер.
Дело в том, что формат каждого поля возвращаемого результата (текстовый или binary) выбирает клиент .
См. https://www.postgresql.org/docs/current/protocol-message-formats.html , сообщение bind.

Leonid KudryavtsevПро остальные типы данных не интересовалсяАналогично. Но, наверное, многие клиентские API используют текстовый формат для большинства типов --- интерпретировать-то проще. ;)

ОзверинPgSQLanonymous3, вы не поняли, как прочесть таблицу? Там ниже есть аномалии, которые ВОЗНИКАЮТ при uncommited read.
При uncommited read могут возникать (почти) любые аномалии, и по стандарту это совершенно нормально.
Какие у Вас проблемы с пониманием таблицы, кстати?

зверинБред, конечно, про postgres и postgre - вы нездоровы? Какая вообще разница.

Хорошо, уважаемый Озвери... какая разница-то, в самом деле?

ОзверунНо если вам очень надо, то вот
https://wiki.postgresql.org/wiki/PostgreSQL_Clients
искать по "postgre "
Агрументируете опечатками? "Вы нездоровы?" ;)