Size: a a a

pgsql – PostgreSQL

2020 June 04

OR

Oleg Rizhkov in pgsql – PostgreSQL
sexst
1 команда и у тебя постгрес, который накатился из непонятно кем сделанного образа, непонятно как работающий и безумно неудобный в банальной работе с приложением внутри контейнера. Даже поправить пару файлов в конфиге уже неудобно.
Докер это не про изолировать на локалхосте разные демоны для собственного удобства и какой-то структурированности в системе. Докер это про собрать образ с новой версией своего приложения и швырнуть его на кластер выполняться, вообще не трогая контейнер в процессе работы.
хм... окей, спасибо.
источник

МШ

Михаил Шурутов... in pgsql – PostgreSQL
Oleg Rizhkov
мне казалось, он, наоборот, - универсальный инструмент. 1 команда - и у тебя постгрес.
А потушил этот докер и нету ни постгреса, ни данных. Где? В /dev/null
источник

SB

Sergey Bezrukov in pgsql – PostgreSQL
Михаил Шурутов
А потушил этот докер и нету ни постгреса, ни данных. Где? В /dev/null
Ну, если до такой степени не читать документацию, то да )
источник

МШ

Михаил Шурутов... in pgsql – PostgreSQL
Sergey Bezrukov
Ну, если до такой степени не читать документацию, то да )
Когда человек про БД в докере говорит: 1 команда и не надо ковыряться в конфигах - он явно не читал того, что действительно надо знать
источник

T

The in pgsql – PostgreSQL
Ну да, генту ставится в 3 команды, мы знаем.
источник

МШ

Михаил Шурутов... in pgsql – PostgreSQL
The
Ну да, генту ставится в 3 команды, мы знаем.
А причём тут генту?
источник

T

The in pgsql – PostgreSQL
Это ж с баша, ну.
https://bash.im/quote/394695
источник

МШ

Михаил Шурутов... in pgsql – PostgreSQL
А, блин, из башки вылетело.
источник
2020 June 05

b

blkmrkt in pgsql – PostgreSQL
А SET search_path TO myschema,public; действует локально внутри сессии, или она конфиг сервера меняет? В доках ни слова об этом.
источник

b

blkmrkt in pgsql – PostgreSQL
Ок нашел, SET всегда меняет параметры либо в сессии либо в трансе.
источник

Д

Диман in pgsql – PostgreSQL
А почему возникла необходимость сёрчпас?
источник

s

svvord in pgsql – PostgreSQL
Всем доброго дня. У нас сегодня ночью выключали свет надолго и сервера выключились не штатно. А после запуска ко мне прибежал виндовый админ с вопросом как так: в службах винды Postgres не запущен, но при этом всё работает =)
Как лечить такую ситуацию понятно, потушить PG посредством pg_ctl и затем штатно запустить через сервисы. Вопрос в том, можно ли "Службы" винды заставить в такой ситуации подождать пока PG проведёт все процедуры по проверке и восстановлению и уже по результатам выяснить статус запущена служба или нет?
источник

G

GoodBye in pgsql – PostgreSQL
svvord
Всем доброго дня. У нас сегодня ночью выключали свет надолго и сервера выключились не штатно. А после запуска ко мне прибежал виндовый админ с вопросом как так: в службах винды Postgres не запущен, но при этом всё работает =)
Как лечить такую ситуацию понятно, потушить PG посредством pg_ctl и затем штатно запустить через сервисы. Вопрос в том, можно ли "Службы" винды заставить в такой ситуации подождать пока PG проведёт все процедуры по проверке и восстановлению и уже по результатам выяснить статус запущена служба или нет?
Вы можете создать микросервис для подобной задачи
источник

G

GoodBye in pgsql – PostgreSQL
svvord
Всем доброго дня. У нас сегодня ночью выключали свет надолго и сервера выключились не штатно. А после запуска ко мне прибежал виндовый админ с вопросом как так: в службах винды Postgres не запущен, но при этом всё работает =)
Как лечить такую ситуацию понятно, потушить PG посредством pg_ctl и затем штатно запустить через сервисы. Вопрос в том, можно ли "Службы" винды заставить в такой ситуации подождать пока PG проведёт все процедуры по проверке и восстановлению и уже по результатам выяснить статус запущена служба или нет?
А вообще такой вопрос в Windows группу
источник

РЖ

Роман Жарков... in pgsql – PostgreSQL
Возможно сервис просто не дождался запуска сервера, а тот долго recovery делал после падения.
Простейший рецепт - не доводить до падения.
источник

i

iwanttobeleve in pgsql – PostgreSQL
Всем доброго времени суток.
Подскажите, пожалуйста, во что может упираться параметр maintenance_work_mem? По какой-то причине он упирается в лимит 178,9 млн строк при сканировании, что соответствует примерно 1гб, при том, что по умолчанию стоит 5гб, а для сессии 10.
ОЗУ более чем достаточно
shared_buffers 40gb,
work_mem 512mb,
eff_cache_size 100g.
В документации не нашел завязки maintenance_work_mem на другие переменные, Linux.
источник

AN

Alexander Nikitin in pgsql – PostgreSQL
а как стало понятно, что что-то куда-то уперлось?
источник

i

iwanttobeleve in pgsql – PostgreSQL
Alexander Nikitin
а как стало понятно, что что-то куда-то уперлось?
Ну один мертвая строка занимает в maintenance_work_mem 6 байтов.
Ранее при увеличении этого параметра количество отсканированных за один раз строк увеличивалось равно пропорционально m_w_m. Но это было только до значения в 1 гиг. Хотя везде пишут, что ограничения на этот параметр в 1 гиг нет.
источник

AN

Alexander Nikitin in pgsql – PostgreSQL
а autovacuum_work_mem у вас -1 или установлен в какое-то значение?
источник

i

iwanttobeleve in pgsql – PostgreSQL
Alexander Nikitin
а autovacuum_work_mem у вас -1 или установлен в какое-то значение?
-1
источник