9404
Чат русскоязычного сообщества PostgreSQL, здесь мы обсуждаем технические вопросы, для поиска работы и предложения вакансий есть группа https://t.me/pgsqljobs For English discussion visit https://t.me/pg_sql
Совокупность тоже наблюдал, но не прям вау. С другой стороны, когда у тебя лежит часть или весь ЦОД - на отчетность уже пофиг
Читать полностью…
Падение канала (админ попутал, провайдер херню выкатил, дворник перебил кабель), выключение электричества (а дизель в генератор забыли залить), падение приложений (видел и ОС, но это совсем отшибленные), шаринг ресурсов у VPS и помеха соседа - это тот маленький список реальных, а не фантастических кейсов...
Читать полностью…
А если вдруг ракета прилетит в ЦОД в это время????
Читать полностью…
Пишите в редис например.
Там и запись отложенная и скорость , никаких расходов лишних, записал и всё
нужны именно последний чекин, история не нужна
Читать полностью…
я не до конца понял твою мысль на самом деле) так что не буду углубляться
Читать полностью…
Просто количество перестановок. Там нет упоминаний про явный join:) ну да он сам получится почти вссенга
Читать полностью…
Причем если поизгаляться и сделать три подзапроса вместо джойнов, то все летает
Читать полностью…
А причем тут канал, потеря транзакции будет если умрет процесс пг внезапно, то есть ракеты и отруб электричества
Читать полностью…
И обычно это всё в один момент, когда отчётность или приложение очень нужно
Читать полностью…
не знаю погугли
это же фантастичные сценарии, падение ОС, отруб электричества, ракеты в цод
ни один вшивый VPS за три рубля просто так не падает, это же сервера, всегда есть хоть какой-то ИБП
даже ноутбуки не падают годами, не смотря на зоопарк софта и активностью ручную
смысл вообще переживать об этом? по дефолту off и забыть об этом просто
там где нужен on это отдельный уникальный случай по сути
synchronous_commit = off поставить можно, это по сути делает то что вы хотите - асинхронная запись
Есть wal_writer_delay например, commit_delay, просто их лучше не трогать без нужды, 80сек должно потянуть в любом виде
80 в сек должно спокойно обновлять, это же ничтожно мало.
А так есть настройки всякие, задерживающие запись
Всем привет. Подскажите плз, как можно пофиксить. У меня в параметрах patroni/postgres одно правильное значение параметра log_line_prefix.
Но в curl patroni отдаёт другое значение (curl http://pgsql-server:8008/config)
Как заставить в curl отдавать верное значение?
ну апсерсов там нет, ибо девайсы делают регистр один раз и если нет записи в таблице там даже на бек запрос не уйдет, а вот апдейты да,
и чую будет плохо, так как pgsql 2 vcpu 4 GB ram
по самым оптимистичным подсчетам 80 up/s
Читать полностью…
а есть возможность создать таблицу с отложенный записью на диск? срочно потребовалась хранить время последнего пинга, rtt, и mnc, lac, cellid, ip
сейчас хотят в ту же таблицу где лежит инфа о девайсах и через update обновлять, но я по голове настучал
ну в документации вот так:
"Setting it to 1 prevents any reordering of explicit JOINs. Thus, the explicit join order specified in the query will be the actual order in which the relations are joined"