в общем случае админа нет

Тогда если админ есть, то оптимально настроить все равно нельзя.

Вот в ceph раньше тоже писали данные в журнал. А сейчас перестали !!!

есть 1С и есть бухгалтер, который умеет гуглить и у которого есть домашний винчестер, а денег на новый для базы нет, а место кончилось, потому что темповые тейблспейсы всё пожрали, но он про них даже не знает, как узнать

постгрес - система общего назначения и должна такое переживать :)

Для этого пусть дефолтные супернадежные и супермедленные настройки будут. Как в qemu cache=writethrough

они и есть

и есть fsync=off и synchronuous_commit=off, как вторая сторона спектра

промежуточных значений маловато, это да - их надо дописывать

Ну это уж совсем.

Не представляю систем, где можно это отключить и чтобы надежность сохранялась

fsync=off у нас на кластере у QA, чтобы тесты быстрее гнались - упадёт так упадёт, база живёт только пока тесты запускаются в этот раз в openstreetmap.org nominatim деплоится под fsync=off, и по успешному деплою включается обратно - всё равно сначала передеплоивать, если что-то пошло не так в нашей локальной базе со статистикой synchronuous_commit=off, база при падении консистентна, а пару секунд данных потерять разок в неделю - ну и чёрт с ними

вопрос приоритетов и определения понятия "надёжность"

Ну. Во всех этих случаях сохранность базы не гарантируется. Оно просто вам не нужно :) у нас тоже тесты в cache=unsafe (qemu) гоняются.

А вообще, с кем можно поговорить еще по моему вопросу? Возможно, с кем-то из PostgresPro ?

ну вот смотри, обесточили вашу железяку, с ней - приложение, которое пишет статистику, и базу, в которую пишется статистика есть в принципе разница - потеряете вы последние 10 инсертов, которые умрут в незакоммиченной транзакции (и не повторятся приложением, потому что оно тоже умрёт) или потеряете последнюю полусекунду данных, которая умрёт в незакоммиченном synchronous_commit, о чём никогда не узнает приложение, потому что оно тоже умрёт? в обоих случаях после поднятия база консистентна, руками ничего чинить не надо. подозреваю, разницы нет, а synchronuous_commit=off ресурс винчестера сбережёт и производительность поднимет.

А вообще, с кем можно поговорить еще по моему вопросу? Возможно, с кем-то из PostgresPro ?

у pgpro можно купить коммерческую поддержку. наши сегфолты они чинят весьма оперативно :)

ну вот смотри, обесточили вашу железяку, с ней - приложение, которое пишет статистику, и базу, в которую пишется статистика есть в принципе разница - потеряете вы последние 10 инсертов, которые умрут в незакоммиченной транзакции (и не повторятся приложением, потому что оно тоже умрёт) или потеряете последнюю полусекунду данных, которая умрёт в незакоммиченном synchronous_commit, о чём никогда не узнает приложение, потому что оно тоже умрёт? в обоих случаях после поднятия база консистентна, руками ничего чинить не надо. подозреваю, разницы нет, а synchronuous_commit=off ресурс винчестера сбережёт и производительность поднимет.

Разумеется, у нас это включено. Но меня злит, что все вставляемые данные два раза пишутся на диск. Можно и пооптимальнее.

"это включено" = включен synchronuous_commit или включен synchronuous_commit=off? :)

А по факту, на знании того, как работают гарантии от ОС, можно сделает нехилые оптимизации, уменьшающие объем записи в два раза.

нету этих гарантий. :( даже в рамках буфер кеша нету атомарности, я для этого даже мелкую прогу писал. При интенсивной записи, когда контекст не переключается всегда есть шанс увидеть/записать промежуточное состояние.

Можно подробнее?

нету этих гарантий. :( даже в рамках буфер кеша нету атомарности, я для этого даже мелкую прогу писал. При интенсивной записи, когда контекст не переключается всегда есть шанс увидеть/записать промежуточное состояние.

все эти чудеса напомнили мне The Night Watch https://www.usenix.org/system/files/1311_05-08_mickens.pdf

Можно подробнее?

пишем 2 проги, одна постоянно пытается записать 8к на диск, другая читает 8к с диска. Это всё одним write и одним read. :) При определённых обстоятельствах вторая прога читает наполовину заполненый файл (первая пишет то одни нули то одни еденицы)

Дак ежу понятно

Поэтому постгрессные процессы же сообща работают

атомарность едрить её :( т.е. даже при том что физически диск тут даже не трогается

Поэтому постгрессные процессы же сообща работают

ага все дружно устроили курилку в локах

А што, нет ?

А што, нет ?

такида

Ну вот и я о чём. На мой вопрос я получил такой ответ: при модификации страницы, постгрес полностью меняет все ее байты в общем случае. Поэтому full page writes нужен.

всё же чаще всего нет

т.е. даже полностью нет

??

одна модификация которая лижит в критикал секции меняет крайне мало

Что ?

другой разговор про то сколько будет изменений прежде чем буфер будет сброшен на диск

Тут говорили что даже селект может дефрагментировать содержимоеодной страницы

Типа вакуумировать ее

да, а что он длает с hint битами....

просто внутри postgres это всё выглядит гораздо более гранулированным

Блин сколько людей - столько и мнений. Есть недиванный эксперт ?

я как бы

Окей, Юрий, я задам вопрос но позже. Сейчас в меге.

ну т.е. я могу говорить за буфер менеджер, его поведение я хорошо знаю

хорошо!

Ну или промотай повыше. Там разговор про то зачем тупли еще и в wal пишутся. Я не понимаю, считаю, что можно сделать и без этого копирования надежно. Как в bluestore от ceph и как в ext4.

ок

Ребята, про машину времени для пг кто сталкивался ?

))))

кто что моет посоветовать менее жрущее ?

все чаще возникает задача откатиться на конкретную минуту в состояниях базы

Снапшоты на фс прокатят ?

Btrfs тоесть

нет

только база

кластерная

хотелось бы услышать тех, кто сталкивался с данным видом журналирования и восстановления

Я где-то встречал крутой доклад как реализовать машину времени средствами view и схем и еще чего-то такого

Можно почитать как работает oracle workspace manager и сделать такое же на посгре. Там вьюхи с копией таблицы и таймстампом используются. Вот и машина времени.

не так давно был доклад Генриетты Домбровской на эту тему: https://postgrespro.ru/blog/company/17879

Я нипонел, тут продолжается это животрепещущее обсуждение, для зачем постгресу ACID? o_O

да

Нет. Я считаю, что можно этого достичь иным способом

почитай фундаментальный пдф где впервые придумали вал каким мы его знаем http://cs.stanford.edu/people/chrismre/cs345/rl/aries.pdf

один из важнейших постулатов — рекавери должен заебись работать на всех данных, быть простым, надеждным и быстрым

ERROR: S client not available

@stalkerg ну что, приступим.

Хотя нет, сначала прочитаю пдф

Вам бы уже по скайпу созвониться, так гораздо быстрее обсуждение пойдет

ну уж нет!

Сразу в кафе?

Собирайте митап

Или вебинар на худой конец

В коворкинге или антикафе?

Дресс код ивента — подвёрнутые штаны? Лекция о веганском борще с митболами и фалафели будет? :)

один из важнейших постулатов — рекавери должен заебись работать на всех данных, быть простым, надеждным и быстрым

Заебись работает только drop database

в постгресе дроп датабейз хуево работает кстати

долго буферпул сканит

как и дроп тейбл

а вот транкейт заебись!

Он не транзакционен же

транкейт в постгресе транзакционен

там делают костыль с подменой файла насколько я помню

но ребята из постгреспро лучше знают

В документации было иное написано

как минимум те которые фаст транкейт предлагают

TRUNCATE is not MVCC-safe. After truncation, the table will appear empty to concurrent transactions, if they are using a snapshot taken before the truncation occurred. See Section 13.5 for more details. TRUNCATE is transaction-safe with respect to the data in the tables: the truncation will be safely rolled back if the surrounding transaction does not commit.

а вот транкейт заебись!

Это да. Лучше чем фулл вакуум.

У меня была пустая таблица весом 170Гб.

Хм.. че то открытие прям

И прям можно trancate table, а потом rollback?

да

написано же

Ух ты. Догнали и перегнали oracle

Кто-нибудь в курсе, pg_upgrade с 9.3 до 9.6 работает без проблем и сюрпризов?

Кто-нибудь в курсе, pg_upgrade с 9.3 до 9.6 работает без проблем и сюрпризов?

А чё ему не работать? На 9.5 нормально работает, не думаю что там что-то изменилось.

главное на 9.6.1

ато может быть сюрприз