> Какой FUD?

Обычный. Вы рассуждаете о том, чего никогда не пробовали, но транслируете какие-то опасения, не так ли?

> Это вы тут как черт из табакерки выскакиваете, как только в чате появляются нужные ключевые слова.

А можно без переходов на личности, придумывания моих мотивов и т.п.?
Я тут участвую в обсуждении разных тем, и то, что Вам кажутся "ключевые слова" — не моя проблема.

>чтобы не включать волшебную абстракцию со своими интересными приколами,

Это с какими же, подробнее?

>  Нет ничего плохого в том, <skip> а просто заблокировать чертову строчечку в таблице accounts в начале транзакции.

Да ещё как есть, как раз. Дело в том, что:
1. Безошибочно "заблокировать чертову строчечку" почти никто в нетривиальной ситуации на самом деле не способен (но самонадеянность аж захлёстывает, как и положено нормальным программистам, о да ;) ).
2. Всё время, потраченное на раздумывание над проблемами concurrency — чаще всего напрасный труд, не относящийся к решаемой высокоуровневой задаче (за который расплачивается работодатель, кстати).

> Обычный. Вы рассуждаете о том, чего никогда не пробовали, но транслируете какие-то опасения, не так ли?

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

Добро пожаловать в волшебный мир DBA: настроить PITR и восстановиться из него может любой дурак, прочитавший документацию, зато заблокировать строку в таблице «счета» перед изменением счета — непосильная задача, надо включать серьязейбол.

Всё же лучше сразу смотреть на "продвинутые" инструменты (но документацию по основам тоже полезно прочитать). :)

Я имел в виду вот это "кроме предубеждений вообще ничего нет, потому что я им ни разу не пользовался".
И да, Вы не могли бы оставить обсуждения чьих-то личностей? Тут чат не про это, если что.

Почему, когда ты с чем-то не согласен, начинаешь что-то про личности писать?

Ты очень кислотный и вечно портишь дискуссию 🤮

> настроить PITR и восстановиться из него может любой дурак, прочитавший документацию

Да, потому что это несложно.

> надо включать серьязейбол.

Добро пожаловать в реальность, где только я (а уж если послушать истории коллег, то и вовсе печально становится) видел сотни случаев того, как "заблокировать строку в таблице" для кого-то оказывалось "непосильной задачей" (с сопутствующими финансовыми потерями), так что лично я в эти сказки больше не верю, извините.

/report

Yaroslav Schekin: Роман Жарков @confguru @Komzpa @pasha_golub @obartunov

Хороша реальность: блокировать строки никто не умеет, зато как работает PITR изнутри — все знают, и уж точно ноги себе не поотстреливают.

(речь, между прочим, идет про ту СУБД, в которой pg_xlog переименовали в pg_wal, чтобы наконец-то все перестали удалять «какие-то логи»)

Какая уж есть.
А зачем для пользования средствами для backup знать, "как работает PITR изнутри"?
Может, для пользования pg_dump теперь тоже нужно знать, как он работает изнутри? ;)

Вот именно. Речь-то о людях, а не о СУБД.
А уж "вручную" управлять concurrency куда сложнее, чем разобраться, что такое pg_xlog.

Без этого разницы никакой, кроме того, что одно работает быстро и весит много, а другое — наоборот.

(ах да, второе еще можно между версиями таскать)

Но и тут есть нЪюансы. Точно говорю!

(в одну сторону)

> Без этого разницы никакой

Без чего "без этого"? Без PITR?
Разница кардинальная — у backups предсказуемое (и короткое, сравнимое с временем копирования) время восстановления, а вот дампы — это лотерея (и куда медленнее, если что)!
Т.е. на дампах надёжную стратегию восстановления не построишь.

Почему же... Имея приличный по размеру и скорости носитель информации вполне себе... (но это только гипотетически)...
Я искренне не понимаю когда резеврную копию (разных разновидностей) обзывают разными словами (причем вражеско язычными и вокруг этого устраивают холивары вместо того чтобы говорить на русском языке в терминах RPO, RTO... и т.п.