Добрый день! Столкнулись с такой пробемой: Недавно переехали на PostgreSQL на Linux версия - PostgreSQL 9.2.18 on x86_64-redhat-linux-gnu, compiled by gcc (GCC) 4.8.5 20150 623 (Red Hat 4.8.5-11), 64-bit И при выполнении бекапа pg_dump съедает всю память и отваливается с ошибкой out of memory Происходит на шаге: pg_dump: saving database definition Killed Особенности БД - очень много blob. Характеристики сервера - 16Gb памяти. Размер БД ~280Gb На старой машине под Windows бекап все-таки выполнялся, но за полтора дня. Посоветуйте с какими вообще настройками можно поиграться чтобы pg_dump отработал? настройки postgresql.conf я так понимаю для этого не сильно подходят, а параметров запуска pg_dump в общем-то не очень и много ...

Если вы внедрите и правильно настроите basebackup (любой из инструментов), то сможете, например, за несколько минут вернуть мастер в состояние по времени на час назад

Народ, привет всем!) Периодически плагин мотиноринга mamonsu теряет соединение с бд, и потом переконнекчивается, из-за чего такое может происходить? Из-за агрессивного сбора показателей? Интервал подключения и сбора занимает больше 1 сек и zabbix ругается? Вот что пишет <-= SED FAIL: Mamonsu plugin errors on db-slave1. Last: catch error: [Errno 104] Connection reset by peer. Total count: 1. on db-slave1 =-> =============*-*-*-*============= Last value: Last: catch error: [Errno 104] Connection reset by peer. Total count: 1. (13:01:57) Original event ID: 3035034 =============:-:-:-:============= Кто-нить сталкивался?

Теряется связь с заббикс-сервером

пм

В pgbouncer в это время были такие записи: closing because: client close request (age=0) closing because: client close request (age=1) и потом переподключение: login attempt: ...

Эм, может у вас количество клиентов к pgbouncer превышено? и соответственно лишнее отсекается

Да-да, я тоже пока на это грешу .... Просто в очереди не дожидается своего часа. Стоит 40, нужно с настройками плагина поиграться, чтобы не так часто ломился или пул увеличить ...

А что вакансию то удалили, я уже хотел затролить за такую вилку? ?

потому что не постгрес

друзья, всем привет, поделитесь пожалуйста опытом есть задача, из jsonb поля вытягивать только определенное property, причем у разных сущностей сам jsonb документ может быть разным и содержать различные property запрос в моем случае содержит вот такой кусочек jsonb_build_object('10055', m.value -> '10055') as value как выяснилось, то разница по времени обращения к полю value и в приведенной конфигурации порядка 600 ms, т.е. выборка конретной property из jsonb поля подтормаживает что посоветуете в этой ситуации ?

Да-да, я тоже пока на это грешу .... Просто в очереди не дожидается своего часа. Стоит 40, нужно с настройками плагина поиграться, чтобы не так часто ломился или пул увеличить ...

Вообще хорошая практика по баунсеру на приложение. Меньше голову ломать приходится

друзья, всем привет, поделитесь пожалуйста опытом есть задача, из jsonb поля вытягивать только определенное property, причем у разных сущностей сам jsonb документ может быть разным и содержать различные property запрос в моем случае содержит вот такой кусочек jsonb_build_object('10055', m.value -> '10055') as value как выяснилось, то разница по времени обращения к полю value и в приведенной конфигурации порядка 600 ms, т.е. выборка конретной property из jsonb поля подтормаживает что посоветуете в этой ситуации ?

мы, если часто обращаемся к какой либо JSON переменной - выносим обычно в отдельное поле. Где-то тут говорили что с JSON как с документориентированной БД работать не самая хорошая идея

мы, если часто обращаемся к какой либо JSON переменной - выносим обычно в отдельное поле. Где-то тут говорили что с JSON как с документориентированной БД работать не самая хорошая идея

Я где-то полгода-год назад планировал использвать JSONB хранения динамичных данных, например частные параметры товара. Тогда как раз и получил совет пересмотреть структуру и минимизировать использование JSON до случаев, когда без них ну уж совсем нельзя

друзья, всем привет, поделитесь пожалуйста опытом есть задача, из jsonb поля вытягивать только определенное property, причем у разных сущностей сам jsonb документ может быть разным и содержать различные property запрос в моем случае содержит вот такой кусочек jsonb_build_object('10055', m.value -> '10055') as value как выяснилось, то разница по времени обращения к полю value и в приведенной конфигурации порядка 600 ms, т.е. выборка конретной property из jsonb поля подтормаживает что посоветуете в этой ситуации ?

Может быть стоит отказаться от jsonb build object это лишняя сериализация. Мы наталкивались на умопомрачительный прирост времени на выполнение, когда использовали jsonb поля в join.

> бизнес > mms

> ICQ

> ICQ

Чё? Это? Щас? Было?

цитата с удаленного спама

а уже обсуждали прекрасное? :) How we almost lost an important client because of MySQL & UTF8 https://www.reddit.com/r/programming/comments/6mksng/how_we_almost_lost_an_important_client_because_of/

Эм, может у вас количество клиентов к pgbouncer превышено? и соответственно лишнее отсекается

Нет, не это, в этом случае другие ошибки. Тут просто сообщения о том, что соединение закрыто клиентом

Ребят, кто использует тулы для миграции изменений БД?

sqitch

Коллеги, нашел тут небольшую бд на 50гб, на ней полностью выключен autovacuum. Вопрос, как долго она ещё проживет?

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

Коллеги, нашел тут небольшую бд на 50гб, на ней полностью выключен autovacuum. Вопрос, как долго она ещё проживет?

ну так проведи руками вакуум

Руками, это понятно, я к тому если вообще не делать

Это прямой путь к концу БД?

Зависит от того, сколько раз в среднем апдейтится каждая строчка. Если в неё только вливают данные, и ни когда не апдейтят, то жить она может бесконечно.

а Wraparound при insert only не грозит?

50ГБ - если вырожденный create table (i int primary key), и вставляют всегда по 1 строчке, то ещё 25 ГБ есть. Если вставляют пачкой по 1000, то до лимита размера таблицы быстрее доберутся ? Но в целом, ты прав: я забыл про wraparound ?

Коллеги, нашел тут небольшую бд на 50гб, на ней полностью выключен autovacuum. Вопрос, как долго она ещё проживет?

а зачем его вообще выключать?

поэтому сначала читать https://www.postgresql.org/docs/current/static/routine-vacuuming.html

потом уже уточнять что из написаного не понятно

а зачем его вообще выключать?

Мопед не мой, попросили разобраться, почему БД падает два раза в день.

в логах все чисто чтоль?

и в postgresql и в системных?

Ребят, кто использует тулы для миграции изменений БД?

можно вбить в поиск и увидеть ответы

Руками, это понятно, я к тому если вообще не делать

если вообще не делать, то после 4ккк транзакций база встанет колом. Учитывая, что селект - это тоже транзакция, то это рано или поздно произойдет

Ребят, кто использует тулы для миграции изменений БД?

yandex-pgmigrate, flyway

Спасибо за ответы, будем подбирать оптимальные параметры autovacuum для небольшой БД

да вы сначала дефолтные просто включите, на мелкой базе вам может и подбирать ничего не придется

посоны, а вот такой вопрос - есть большая хранимка которая в одной транзакции выгребает кучу данных и апдейтит записи определённые в таблице. что будет если какую-то из записей в лупе не удастся проапдейтить? ролллбэк всего или запись будет проигнорирована и дальше всё будет фигачаить?

посоны, а вот такой вопрос - есть большая хранимка которая в одной транзакции выгребает кучу данных и апдейтит записи определённые в таблице. что будет если какую-то из записей в лупе не удастся проапдейтить? ролллбэк всего или запись будет проигнорирована и дальше всё будет фигачаить?

Если возникнет исключение, которое вы не обработаете, то, конечно, вся транзакция откатится.

а хранимка дефакто как одна транзакция работает?

там просто куча условий и апдейтов по блокам разбито

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

Хранимки в постгре всегда одна транзакция.

Functions are atomic in Postgres and automatically run inside their own transaction unless called within an outer transaction. They always run inside a single transaction and succeed or fail completely. Consequently, one cannot begin or commit transactions within the function. 

Всем привет! Написал свой первый экстеншен для постгрес: MonQ - https://github.com/postgrespro/monq . MonQ позволяет совершать запросы к json документам на языке запросов MongoDB. Так как экстеншен разрабатывался в учебных целях, просьба потестить и оценить его. Критика и рекомендации приветствуются)

Вау

Привет! Подскажите, настроил логи postgres на другой диск и сделал ротацию на 1Гб, но файл все равно вырастает больше 1Гб, что забыл в конфиге? log_destination = 'stderr' logging_collector = on log_directory = '/mnt/logs/' log_filename = 'postgresql.log' log_rotation_sizelog_rotation_size = 1GB

ERROR: S client not available

Базу рестартовали? Есть подозрение, что log_filename ещё неверный.

Попробуйте что-нибудь вроде postgresql-%Y-%m-%d_%H%M%S.log

так он и не верный)

А то он не знает, как ему куски называть.

Базу рестартовали? Есть подозрение, что log_filename ещё неверный.

рестартовал, начало писаться в другое место, может быть это нужно log_truncate_on_rotation=on?

так он и не верный)

а что не так?)

Попробуйте что-нибудь вроде postgresql-%Y-%m-%d_%H%M%S.log

Попробуйте что-нибудь вроде postgresql-%Y-%m-%d_%H%M%S.log

а log_truncate_on_rotation=on если делать и писать в один файл?

на лету могу изменить параметры, или нужен будет рестарт сервера?

pg_ctl reload должен помочь

ок, сейчас попробую, а мой вариант не подойдёт если оставить то же имя файла?

Ребят, если одно из полей в select у меня json_array_elements(workout_elements.series::json)->>'weight' AS weight```и я хочу посортировать по нему потом, то мне в ORDER BY можно вписать ```ORDER BY weight DESC```или же ```ORDER BY json_array_elements(workout_elements.series::json)->>'weight' DESC? и вообще все в порядке с сортированием по данному полю будет? возвращаемое значение этой функции будет типом SETOF json

коллеги, а как можно посчитать max_locks_per_transaction?

начали сыпаться вот такие сообщения:

PG::OutOfMemory: ERROR: out of shared memory HINT: You might need to increase max_locks_per_transaction. : SELECT "hourly_stats_partitioned_view".* FROM "hourly_stats_partitioned_view" WHERE "hourly_stats_partitioned_view"."resource_type" = 'Social::ExternalPublication' AND "hourly_stats_partitioned_view"."resource_id" = 16803496 AND "hourly_stats_partitioned_view"."kind" = 'link_click' AND (date >= '2017-07-08 17:07:38.000000') ORDER BY "hourly_stats_partitioned_view"."id" DESC LIMIT 1

ну не факт что max_locks_per_transaction :)

в описании max_locks_per_transaction вижу: > you might need to raise this value if you have queries that touch many different tables in a single transaction, e.g. *query of a parent table with many children*

то есть в принципе-то подходит

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

query plan по этому запросу вообще какой-то детский

git grep 'You might need to increase max_locks_per_transaction' | grep \.c\: src/backend/storage/lmgr/lock.c: errhint("You might need to increase max_locks_per_transaction."))); src/backend/storage/lmgr/lock.c: errhint("You might need to increase max_locks_per_transaction."))); src/backend/storage/lmgr/lock.c: errhint("You might need to increase max_locks_per_transaction."))); src/backend/storage/lmgr/lock.c: errhint("You might need to increase max_locks_per_transaction."))); src/backend/storage/lmgr/lock.c: errhint("You might need to increase max_locks_per_transaction."))); src/backend/storage/lmgr/lock.c: errhint("You might need to increase max_locks_per_transaction.")));

ну в принципе да

http://tatiyants.com/pev/#/plans/plan_1499863450098

вот так выглядит план

что-то я не очень понимаю, на чем оно тут взрывается