Параметр закоментирован

Первое - а на каком запросе все падает? Ну и второе, отпишитесь в постгресовый багрепорт.

Первое - а на каком запросе все падает? Ну и второе, отпишитесь в постгресовый багрепорт.

Запрос самый обычный, select from inner join

А можно схему задействованных таблиц и сам запрос? Ну или сами проверьте его на тестовой схеме с нагенерированными данными. Если повторяется сегфолт, вам 100% на багтрекер. Если нет, то можно попробовать подключиться по gdb

https://pastebin.com/KZzUAJ7s

Есть смысл полностью отключить huge pages?

Вы нашли какую-то проблему с памятью при выполнении вашего запроса в случае параллельного сканирования. Если есть возможность исключить влияние huge pages, сделайте это.

Ок, спасибо, будем экспериментировать.

Всем привет. Вопрос немного не в тот чат, но иного у меня нет :) В БД есть понятие "нормализация", аналогично в программировнии есть правило, при котором 1 класс должен выполнять 1 простую логику. Не помню название как оно официально называется. кто знает скажите пожалуйста Ответ на опережение: поиск юзал.

сингл респосивити

сингл респосивити

спасибо

Респонсибилити

всем привет, ссорян за глупый вопрос а чем отличается insert от update спасибо заранее

всем привет, ссорян за глупый вопрос а чем отличается insert от update спасибо заранее

https://ru.wikipedia.org/wiki/Update_(SQL) https://ru.wikipedia.org/wiki/Insert_(SQL)

Апдейт это делит и инсерт вроде

В одном флаконе :)

Спасибо большое :))

Апдейт это делит и инсерт вроде

но есть исключения...

но есть исключения...

Какие?

HOT updates например

При хот апдейтах тоже создаётся новая версия тупла, только индекс не обновляется. В itemid помещается редирект

и происходит все это только в рамках одной странички... в курсе. Однако Update != Delete + Insert

Ну в старый тупл ставится xmax и создаётся новый. Это по сути то же самое, что делает delete+insert

Апдейт это делит и инсерт вроде

В общем случае нет, например, за fdw апдейт может быть не-mvcc хранилище и апдейт станет апдейтом

Еще insert умеет обрабатывать уник конфликты.

Хороший вопрос кстати для тех. интервью

Еще insert умеет обрабатывать уник конфликты.

А как их не умеет обрабатывать update?

Ну в старый тупл ставится xmax и создаётся новый. Это по сути то же самое, что делает delete+insert

однако даже если рассматривать только страничку с таплом который обновили. Она не будет идентичной после update и transasction(delete + insert)

Апдейт на существующее значение

Апдейт на существующее значение

По идее в апдейте ты это можешь и сам разрулить, через какое-нибудь where not exists и вычислимое значение в set

Это в insert нужен on conflict update, потому что ты тапл или создаешь, или обновляешь

По идее в апдейте ты это можешь и сам разрулить, через какое-нибудь where not exists и вычислимое значение в set

Можно не спорю, даже лучше использовать IS DISTINCT FROM.

Можно не спорю, даже лучше использовать IS DISTINCT FROM.

is distinct from к чему в случае конфликта?

Вместо not exists

Как ты организуешь отсутствие конфликта после апдейта через is distinct from внутри update?

Сап народ, кто-нибудь сталкивался со сломанным внешним архиватором? $ pg_dump -Fc > dump.gz postgrespro-9.6.4 " pg_dump: [внешний архиватор] ПРЕДУПРЕЖДЕНИЕ: позиция ftell не соответствует ожидаемой -- используется ftell"

А место на диске точно не кончилось?

Место есть, туда же без кастомного формата без проблем создается

не винда случайно?

Проверил все-таки cent os, беглое гугление привело: а) у вас кончилось место б) проверьте что не винда :)

Вообще технически он что-то и так пишет, я просто не риснул ждать. Причем даже на пустой схеме

попробуй -f вместо редиректа

алсо это не .gz

Ребята, расскажите как сейчас модно\правильно обновлять субд до 9.6 без простоя и используя новый сервер? какой из инструментов наиболе прост и работает как заявлено: slony, londiste, pgpool, pgbouncer?

Ребята, расскажите как сейчас модно\правильно обновлять субд до 9.6 без простоя и используя новый сервер? какой из инструментов наиболе прост и работает как заявлено: slony, londiste, pgpool, pgbouncer?

модно со спинером

в левой руке

@vadvmkn делитесь лучше опытом миграций\обновлений :) а не вот этим вот.

@vadvmkn делитесь лучше опытом миграций\обновлений :) а не вот этим вот.

если вы хотите узнать личное мнение - если не одним из slony, londiste и pgpool (не дай бог) еще не пользуетесь, то обновление через них без остановки - реальный оверхед для этого

pgpool и pgbouncer - даже не знаю чем поможет (RO копия?)

Что тогда посоветуете?

Что тогда посоветуете?

регламентные работы и pg_dump && restore

без переходных версий, прям на последнюю, которая вас устраивает

а до этого тестировать новую версию и тренироваться как сделать restore быстрее чтобы востанавливать в несколько потоков

бинарный апгрейд - конечно хорошо, но я никогда ему не доверял, сорян :(

этот вариант мне нравится больше всего. но есть вопросы, будет ли достаточно времени для плановых работ и делать ли при этом pg_upgrade или это излишне?

https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=e95c4bd1133acf7fc58a52212253129ef2dc9d12

этот вариант мне нравится больше всего. но есть вопросы, будет ли достаточно времени для плановых работ и делать ли при этом pg_upgrade или это излишне?

^^^ про pg_upgrade

выше читайте. я бы использовал pg_dump && restore

представляете сколько может жить ошибка в pg_upgrade

ок. благодарю за ответы.

на pgday рассказывали как обновляются с pglogical. Поднимают логическую реплику, догоняются и включают ее как основной сервер. Сам не пробовал, но вроде как должен быть минимальный даунтайм

pglogical уже умеет весь инстанс или до сих пор одной базой всё ограничено?

ERROR: S client not available

хз

на pgday рассказывали как обновляются с pglogical. Поднимают логическую реплику, догоняются и включают ее как основной сервер. Сам не пробовал, но вроде как должен быть минимальный даунтайм

Басни! На той неделе Артем обновился до сих пор бомбит!

Басни! На той неделе Артем обновился до сих пор бомбит!

а с чем проблемы?

Как только включаем его, то получаем terminated by signal 11: Segmentation fault

Вот

Вот

ВРЕТИ

ВРЕТИ

Мы ещё и не так могём!

регламентные работы и pg_dump && restore

А если бд больше 10GB? Например over 100GB? dump - от 1 часа restore - от 2-3 часов

Тогда не обновляйте :) Авито до сих пор на 9.2 :)

Тогда не обновляйте :) Авито до сих пор на 9.2 :)

А как обновлять будут? Чем дальше, тем тяжелее не?

А как обновлять будут? Чем дальше, тем тяжелее не?

И так работает! Бизнес бабки приносит! Зачем?

И так работает! Бизнес бабки приносит! Зачем?

Упрутся в какую-нить багу которая зафикшена на следующем мажоре, и несколько фич нужных. Например, так.

А если бд больше 10GB? Например over 100GB? dump - от 1 часа restore - от 2-3 часов

Рестор в несколько потоков (индексы в один поток) через несколько бакендов, вручную через psql. 400 gb за пару+тройку часов укладывается, если не оч много индексов

А так вообще вам самим нужно решать- что важнее целостность данных или несколько часов на майнтенс

Упрутся в какую-нить багу которая зафикшена на следующем мажоре, и несколько фич нужных. Например, так.

Исправления бэкпортят в саппортед версии

Фичи - да. Но фичи деньги помогут зарабатывать или самолюбие разраба будет тешить?

Фичи - да. Но фичи деньги помогут зарабатывать или самолюбие разраба будет тешить?

Я тут сказал бы самолюбие;)

Исправления бэкпортят в саппортед версии

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

Ну, мускул погоди!

Ну, мускул погоди!

Это же у убер такой переход был? С мускул и обратно? Точно ;) https://eng.uber.com/mysql-migration/

Вот и разрабы потешились!

А как обновлять будут? Чем дальше, тем тяжелее не?

Там достаточно посмотреть на дизайн, чтобы понять, что обновление - это слово немного не про них

этот вариант мне нравится больше всего. но есть вопросы, будет ли достаточно времени для плановых работ и делать ли при этом pg_upgrade или это излишне?

Я всегда делал через pg_upgrade, пока ничего не сломалось, инстансы были от нескольких ГБ до сотен. Если делать через хардлинки, то upgrade быстрый в 1 час можно уложится, но тут уже обязателен бекап БД иначе откатываться некуда будет.

Я всегда делал через pg_upgrade, пока ничего не сломалось, инстансы были от нескольких ГБ до сотен. Если делать через хардлинки, то upgrade быстрый в 1 час можно уложится, но тут уже обязателен бекап БД иначе откатываться некуда будет.

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

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

Ну да, к тому же инстансы некоторые были с чексуммами. И в процессе дальнейшей работы пока ничего не сломалось.

чек суммы не зашищают

по крайней мере от всего :)

выкрутасов файловой системы

ща :)

/usr/lib/postgresql/9.6/bin/initdb -D main -k /usr/lib/postgresql/9.6/bin/pgbench -i -s 100 postgres=# select count(*) from pgbench_accounts; count —------— 10000000 (1 row) postgres=# \q postgres@ubuntu:~/9.6$ rm -f main/base/12439/16396.1 postgres@ubuntu:~/9.6$ psql psql (9.6.4) Type "help" for help. postgres=# select count(*) from pgbench_accounts; count —------- 7995392 (1 row) postgres=#