только все равно это не твое приложение

но я хз что у вас за цель теста конечно

скорее всего холиварной направленности

да просто тут возник бутч по поводу того, использовать ли в кластере pg с data=nojournal

или нет

да просто тут возник бутч по поводу того, использовать ли в кластере pg с data=nojournal

Нет такой опции у экст4

-O ^has_journal не работает?

dumpe2fs говорит что работает

а разница "на ноуте" не заметна

есть journal, ordered и writeback

xfs работает как writeback. никто вроде не жалуется

xfs работает как writeback. никто вроде не жалуется

На экст4 при вырубании питания и врайтбеком если файл был зааппенден, в аппендной области может быть мусор

есть journal, ordered и writeback

я не про опции монтирования

я про tune2fs

https://gist.github.com/vadv/ca23cd06439607c0b6fd408543369dd3

вот разница между -j и -O ^has_journal

я про tune2fs

Это тоже самое. Только тюне2фс высавляет дефолты

вот разница между -j и -O ^has_journal

Без журнала при выключении будет коррапт фс

> Journal features: (none) > Journal size: 128M > Journal length: 32768 > Journal sequence: 0x00000001 > Journal start: 0

Без журнала при выключении будет коррапт фс

вопрос про "отказоустойчивый" кластер в котором нода должна создаваться перезаливкой

На экст4 при вырубании питания и врайтбеком если файл был зааппенден, в аппендной области может быть мусор

xfs тоже в тыкву превращается при отключении питания при записи

погоди, ты щас говоришь что вообще жернал отключал что ли

xfs тоже в тыкву превращается при отключении питания при записи

Пруф

Пруф

Опыт.

Опыт.

Это просто баг значит

тоже интересно :) был баг при малом кол-ве свободного места открытые файлы "транкейтились"

прям как pg с репликой в эпоху 9.2 :)

Это просто баг значит

Возможно, я не проводил эксперименты.

тоже интересно :) был баг при малом кол-ве свободного места открытые файлы "транкейтились"

Если непрофсинкали то фс имеет право это делать

Если непрофсинкали то фс имеет право это делать

я не говорю что имеет или нет. я говорю что pg накатит на файл wal и легализует пустое место

я не говорю что имеет или нет. я говорю что pg накатит на файл wal и легализует пустое место

В принципе фулл пейдж врайтс закрывает эти особенности, да

В принципе фулл пейдж врайтс закрывает эти особенности, да

нет

просто kill -9 && > /path/file и посмотрите что станет с файлом

Штэ

если в wal была запись - записать в блок 100

то появится 99 пустых блоки в самом начале

Штэ

угу

то появится 99 пустых блоки в самом начале

Ну да

Сам по себе файл не может протрункейтиться если он ранее был профсинкан

Сам по себе файл не может протрункейтиться если он ранее был профсинкан

открытые на чтение

Либо это просто космических масштабов баг

было-было, ~ 2.6.32 (vanilla)

А есть линк на багтрекер ?

А есть линк на багтрекер ?

усилено ищу :) но внутренний тикет закрыли ссылкой на bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=845233#c8

но было и что-то другое

Under certain circumstances, a system crash could result in data loss on XFS file systems. If files were created immediately before the file system was left to idle for a long period of time and then the system crashed, those files could appear as zero-length once the file system was remounted. This occurred even if a sync or fsync was run on the files. This was because XFS was not correctly idling the journal, and therefore it incorrectly replayed the inode allocation transactions upon mounting after the system crash, which zeroed the file size. This problem has been fixed by re-instating the periodic journal idling logic to ensure that all metadata is flushed within 30 seconds of modification, and the journal is updated to prevent incorrect recovery operations from occurring. (BZ#856685)

Какой кошмар. Интересно, это редхадники своими патчами внесли или в ванильке было ?

Либо это просто космических масштабов баг

Так и есть

ни разу не видел использования XFS кроме как для хранения простыней очень маловажных файлов (типа аватарок). Может быть именно по этому?

Xfs в кепке рекомендованный вроде как

Дак это в 7

Я использую xfs, считаю что любая фс рано или поздно факапит, xfs несколько стадий прошла и заслужила доверия. Немаловажный фактор, что она fs по умолчанию, да

В семёрке максимальной

ERROR: S client not available

Простите за дурной вопрос

при использовании pg_advisory_xact_lock, при коммите или роллбеке лок снимается же?

как-то не очень хорошо в документации тема раскрыта

>pg_advisory_xact_lock works the same as pg_advisory_lock, except the lock is automatically released at the end of the current transaction and cannot be released explicitly.

я не понимаю что не понятно в automatically released at the end of the current transaction

не понятно что один кусок документации размазан по двум разделам, но спасибо

доброй ночи, господа

Ребята, а есть нюансы в настройках pgsql для лучшей производительности если сравнивать raid 1 и raid 10 ?

ну разве что effective io concurency

и random page cost

но это скорее про кол-во жестких дисков чем про тип рейда

что это?

кому они нужны?

в каком городе, для начала

Кого то учить будут

хотя к чёрту город, страна какая? :)

ну вот

теперь мы не узнаем :)

но вообще, в стародавние времена под такое, бывало, зал в интернет-кафе снять можно было

Господа, а есть ли у вас какие-нибудь склонности к хранению данных в колонках vs json? При прочих равных

У меня такая ситуация, в базе лежат довольно сложные данные, если каждый элемент рассовывать по колонке, то получится таблица где примерно 80-90 колонок. Я всегда стремился как можно больше вытащить из json в колонки, но тут даже не знаю хорошо ли это.

В будущем усложняться будет?

будет

Но вложенности элементов не должно возникнуть

То есть формально говоря задача заключается в том чтобы хранить длинные словари данных.

То есть формально говоря задача заключается в том чтобы хранить длинные словари данных.

а может, нормализовать и хранить какнибудь в виде кей-валуе построчно в таблице?

Господа, а есть ли у вас какие-нибудь склонности к хранению данных в колонках vs json? При прочих равных

Склонность есть, если эта колонка обязательно должна быть индексируема, если она на верхнем уровне, и она апприори никогда не пропадет из json-схемы.

а может, нормализовать и хранить какнибудь в виде кей-валуе построчно в таблице?

Это как? Не очень понял