в смысле, какая-то умная часть системы запускает, видит, что за 30 секунд не запустилось, убивает и запускает заново? :)

> Запустил, и в логах после попыток восстановления - бесконечные попытки старта. Так покажите их (эти попытки рестарта и восстановления)!

в смысле, какая-то умная часть системы запускает, видит, что за 30 секунд не запустилось, убивает и запускает заново? :)

Да, здесь сборная солянка из баз для SIEM-системы.

Имя службы : PostgreSQL.PTMS Отображаемое имя : PostgreSQL.PTMS - PostgreSQL Server 9.6 Исполняемый файл : "F:\Program Files\Positive Technologies\Common\PostgreSQL\bin\pg_ctl.exe" runservice -N "PostgreSQL.PTMS" -D "F:\Program Files\Positive Technologies\Common\PostgreSQL\data" -w Состояние : Остановлена Тип запуска : Авто Взаимодействие с рабочим столом : Нет Собственный процесс : Да Вход в систему : NT AUTHORITY\NetworkService

> Состояние: Остановлена Вот это настораживает. Может, в настройках этой службы есть какой-то timeout на запуск?

Вот такого рода события в логе: 2018-08-06 21:44:55 +07 FATAL: the database system is shutting down 2018-08-06 21:44:57 +07 LOG: database system is shut down 2018-08-06 21:56:52 +07 LOG: database system was shut down in recovery at 2018-08-06 21:44:53 +07 2018-08-06 21:56:52 +07 LOG: database system was not properly shut down; automatic recovery in progress 2018-08-06 21:56:52 +07 FATAL: the database system is starting up 2018-08-06 21:56:52 +07 FATAL: the database system is starting up 2018-08-06 21:56:52 +07 FATAL: the database system is starting up 2018-08-06 21:56:52 +07 FATAL: the database system is starting up 2018-08-06 21:56:52 +07 FATAL: the database system is starting up 2018-08-06 21:56:53 +07 FATAL: the database system is starting up 2018-08-06 21:56:54 +07 FATAL: the database system is starting up 2018-08-06 21:56:55 +07 LOG: redo starts at 2/29EB118 2018-08-06 21:56:55 +07 FATAL: the database system is starting up 2018-08-06 21:56:56 +07 FATAL: the database system is starting up 2018-08-06 21:56:57 +07 FATAL: the database system is starting up 2018-08-06 21:56:57 +07 FATAL: the database system is starting up 2018-08-06 21:56:57 +07 FATAL: the database system is starting up 2018-08-06 21:56:58 +07 FATAL: the database system is starting up 2018-08-06 21:56:58 +07 FATAL: the database system is starting up 2018-08-06 21:56:59 +07 FATAL: the database system is starting up

если есть таймаут на запуск, нужно его убрать :)

Вот такого рода события в логе: 2018-08-06 21:44:55 +07 FATAL: the database system is shutting down 2018-08-06 21:44:57 +07 LOG: database system is shut down 2018-08-06 21:56:52 +07 LOG: database system was shut down in recovery at 2018-08-06 21:44:53 +07 2018-08-06 21:56:52 +07 LOG: database system was not properly shut down; automatic recovery in progress 2018-08-06 21:56:52 +07 FATAL: the database system is starting up 2018-08-06 21:56:52 +07 FATAL: the database system is starting up 2018-08-06 21:56:52 +07 FATAL: the database system is starting up 2018-08-06 21:56:52 +07 FATAL: the database system is starting up 2018-08-06 21:56:52 +07 FATAL: the database system is starting up 2018-08-06 21:56:53 +07 FATAL: the database system is starting up 2018-08-06 21:56:54 +07 FATAL: the database system is starting up 2018-08-06 21:56:55 +07 LOG: redo starts at 2/29EB118 2018-08-06 21:56:55 +07 FATAL: the database system is starting up 2018-08-06 21:56:56 +07 FATAL: the database system is starting up 2018-08-06 21:56:57 +07 FATAL: the database system is starting up 2018-08-06 21:56:57 +07 FATAL: the database system is starting up 2018-08-06 21:56:57 +07 FATAL: the database system is starting up 2018-08-06 21:56:58 +07 FATAL: the database system is starting up 2018-08-06 21:56:58 +07 FATAL: the database system is starting up 2018-08-06 21:56:59 +07 FATAL: the database system is starting up

Да, 100% что-то останавливает PostgreSQL: > database system was shut down in recovery at 2018-08-06 21:44:53 +07 После чего что-то его опять пытается стартовать: > LOG: database system was not properly shut down; automatic recovery in progress Вам нужно найти, что его останавливает.

Вот такого рода события в логе: 2018-08-06 21:44:55 +07 FATAL: the database system is shutting down 2018-08-06 21:44:57 +07 LOG: database system is shut down 2018-08-06 21:56:52 +07 LOG: database system was shut down in recovery at 2018-08-06 21:44:53 +07 2018-08-06 21:56:52 +07 LOG: database system was not properly shut down; automatic recovery in progress 2018-08-06 21:56:52 +07 FATAL: the database system is starting up 2018-08-06 21:56:52 +07 FATAL: the database system is starting up 2018-08-06 21:56:52 +07 FATAL: the database system is starting up 2018-08-06 21:56:52 +07 FATAL: the database system is starting up 2018-08-06 21:56:52 +07 FATAL: the database system is starting up 2018-08-06 21:56:53 +07 FATAL: the database system is starting up 2018-08-06 21:56:54 +07 FATAL: the database system is starting up 2018-08-06 21:56:55 +07 LOG: redo starts at 2/29EB118 2018-08-06 21:56:55 +07 FATAL: the database system is starting up 2018-08-06 21:56:56 +07 FATAL: the database system is starting up 2018-08-06 21:56:57 +07 FATAL: the database system is starting up 2018-08-06 21:56:57 +07 FATAL: the database system is starting up 2018-08-06 21:56:57 +07 FATAL: the database system is starting up 2018-08-06 21:56:58 +07 FATAL: the database system is starting up 2018-08-06 21:56:58 +07 FATAL: the database system is starting up 2018-08-06 21:56:59 +07 FATAL: the database system is starting up

И отфильтруйте эти "FATAL: the database system is starting up", они вообще к делу не относятся.

ОК, очень логично.

ОК, очень логично.

Вообще да, таймаут можно вообще убрать, т.к. в зависимости от нагрузки и настроек checkpoint, на recovery может уйти и час, например... Конечно, в этом случае лучше настройки PostgreSQL "подкрутить" к нужному Вам RTO. ;)

Вообще да, таймаут можно вообще убрать, т.к. в зависимости от нагрузки и настроек checkpoint, на recovery может уйти и час, например... Конечно, в этом случае лучше настройки PostgreSQL "подкрутить" к нужному Вам RTO. ;)

Дельно, спасибо, учту.

А что же, коллеги, кому-то интересен CTE inlining patch (который в -hackers David Fetter выкладывал)? ;) Если да, есть какие-то идеи, как это должно выглядеть на "уровне" SQL? Т.е., по умолчанию, или GUC, или типа "WITH INLINED a(a, b) AS (...)", или ещё как-то?

оно должно делать это само

оно должно делать это само

Ok. А изменения поведения просто документируем как incompatible change (и/или добавляем GUC), и всё?

а почему оно incompatible?

результат-то у запроса тот же, только план другой?

Нет, не тот же. Более того, достигнуть этого в общем случае невозможно, т.е. сразу оставьте надежду.

почему не тот же?

почему не тот же?

http://www.postgresql-archive.org/CTE-inlining-td5958992i80.html#a5961086 Т.е. если мы хотим patch, надо быть готовым к тому, что изменения будут.

И это, кстати, ещё не всё. Например, может изменится (и, с patch-ем как он есть сейчас, меняется) поведение недетерминированных запросов.

Конкретно, в случае multi-referenced CTE.

это - нормально

ведь пережили изменение поведения SRF

есть в постгресе много бед с инлайнингом

это - нормально

Но это incompatible change. Т.е. если кто-то на это закладывался (и документация-то почти гаранитровала, что это должно работать), у них работать перестанет.

потестируют, не обновятся, перепишут

потестируют, не обновятся, перепишут

Я вот тоже за такой поход, между прочим. ;) Просто интересны другие мнения...

просто окажется, что много кто заложился на cte как на няшный optimization barrier

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

просто окажется, что много кто заложился на cte как на няшный optimization barrier

Это да, но они найдут, эээ... другие способы. ;) Но то, что я описывал/показывал, куда хуже. Это не optimization barrier, это изменение результата запросов. И вот это людям может куда меньше понравиться. :(

это хороший вопрос - можно ли заинлайнить z(v) в том запросе?

по-моему там единственное препятствие - это завышенный кост неравенства

это не единственное такое больное место, https://carto.com/blog/inside/postgres-parallel/

по-моему там единственное препятствие - это завышенный кост неравенства

Да конечно можно. Это действительно IMMUTABLE функция, чего бы её и не inline-ить?

народ. хелп ми

Да конечно можно. Это действительно IMMUTABLE функция, чего бы её и не inline-ить?

ну, нельзя, потому что у неё кост выше трешхолда

я запутался. распутайте меня ))

короч, мне нужны ответы на нубские вопросы )

Да конечно можно. Это действительно IMMUTABLE функция, чего бы её и не inline-ить?

вот есть отличный патч на такое https://patch-diff.githubusercontent.com/raw/CartoDB/postgres/pull/12.diff

делаю кластер кипаливед + хапрокси + посгри

ну, нельзя, потому что у неё кост выше трешхолда

Это я сделал только для того,чтобы показать проблему. Т.е. сейчас CTE подходит для управления порядком выполнения, а после — перестанет.

но при падении кипалива, посгри перезжает на слейв.

кто поможет разобрать проблему . тому конфетку ))

Это я сделал только для того,чтобы показать проблему. Т.е. сейчас CTE подходит для управления порядком выполнения, а после — перестанет.

ну, будет в гайде для миграции "допишите offset 0 во все ваши cte"

@AnastasiyaGurinovich будет жить. Поприветствуем!

ну, будет в гайде для миграции "допишите offset 0 во все ваши cte"

Ну... это не совсем одно и то же. Кроме того, некоторым очень нравится идея вообще упоминать этот hint чем меньше, тем лучше. ;)

да! :)

вообще, кажется, что оптимизация во втором запросе нелегальная

вообще, кажется, что оптимизация во втором запросе нелегальная

Легальная. Точнее, так — или такое легально, или patch можно выбросить, и о CTE inlining забыть. Вам как больше нравится? ;)

мне интересно, exception AND false сворачивается, получается, в exception?

тогда false AND exception тоже должен так же сворачиваться, ведь AND симметричен

а значит, что логика у нас состоит из true, false, null, exception и кейс с exception забыли рассмотреть

а если false AND exception => false, то после эксепшена надо посчитать другие клаузы и если они false, проигнорить эксепшен?

это, кстати, проблема в PostGIS

если ты начнёшь делать join по ST_Intersects по таблицам с двумя разными SRID, то ты получишь или не получишь exception в зависимости от того, созданы у тебя индексы по геометрии или нет

а значит, что логика у нас состоит из true, false, null, exception и кейс с exception забыли рассмотреть

Ну да, вроде того. Но! После долгих и мучительных чтений стандарта (Andrew Gierth, Vik Fearing... ещё кто-то участвовал, забыл :( ), нам показалось, что случай с exception стандарт не считает нужным рассматривать вообще. Т.е., для запроса: SELECT 1 WHERE true OR 1/0; Оба результата — 1 и "division by zero" — соответствуют ISO SQL.

то есть implementation defined, и тогда меняйте ради бога

Да, и это логично, иначе вообще мало что можно было бы оптимизировать.

тогда, кажется, единственный обещанный способ прятать эксепшены - это под case when

если не брать в расчёт plplgsql

тогда, кажется, единственный обещанный способ прятать эксепшены - это под case when

Вообще, нет. Этого ISO SQL тоже не обещает. Т.е. на expection-ы стандарту совсем пофиг. Т.е. если кто-то может оптимизировать CASE так, чтобы "доставать" до exception даже в том случае, когда его не должно быть — тоже молодец. ;) И, кстати, PostgreSQL в некоторых случаях может.

ERROR: S client not available

Прямо из документации, например: https://www.postgresql.org/docs/current/static/sql-expressions.html#SYNTAX-EXPRESS-EVAL

Многие другие СУБД это вообще делают без зазрения совести, а уж при CTE inlining почти никто (кроме DB2) вообще не обращает внимания, что там внутри. ;)

Как можно направлять select запросы на slave сервера, и остальные запросы - на мастер? Сейчас поднят кластер patroni, конфигурация хранится в etcd. И нужно сделать так чтобы при смене мастера конфигурация haproxy(или иного прокси) автоматически обновлялась.

Есть ли готовые решения для этого?

У patroni есть возможность проверки, является ли текущий сервер мастером, и есть готовые конфиги для haproxy, но haproxy не умеет различать запросы к postgres

всем привет, может кто помочь разобраться почему в данном примере первая функция не хочет работать, а вторая нормально отрабатывает - http://sqlfiddle.com/#!17/dd0dd3/29

всем привет, может кто помочь разобраться почему в данном примере первая функция не хочет работать, а вторая нормально отрабатывает - http://sqlfiddle.com/#!17/dd0dd3/29

причем если поменять returns setof record на returns table(title text) и убрать выходные параметры то все ок

У patroni есть возможность проверки, является ли текущий сервер мастером, и есть готовые конфиги для haproxy, но haproxy не умеет различать запросы к postgres

Аналог https://github.com/jhunt/pgrouter/blob/master/README.md

Т.е. запросы на чтение отправлять на одни сервера, а запросы на запись - на другие

Т.е. запросы на чтение отправлять на одни сервера, а запросы на запись - на другие

в приложении укажи одну базу мастер, другую - реплику, базы pgbouncer

в приложении укажи одну базу мастер, другую - реплику, базы pgbouncer

В смысле в самом приложении?

если надо разделять запросы прозрачно для клиента, то это умеет pgpool например. Pgbouncer не умеет и он не для этого

В смысле в самом приложении?

в приложении ты пишешь, что база для записи (точнее мастер) - db_master а бд для чтения - db_replica

причем если поменять returns setof record на returns table(title text) и убрать выходные параметры то все ок

"Потому что". ;) https://www.postgresql.org/docs/10/static/plpgsql-control-structures.html Конкретно, вот это: Note that you must declare the function as returning SETOF record when there are multiple output parameters, or SETOF sometype when there is just one output parameter of type sometype, in order to create a set-returning function with output parameters. Т.е. в первом случае должно быть returns setof text.

"Потому что". ;) https://www.postgresql.org/docs/10/static/plpgsql-control-structures.html Конкретно, вот это: Note that you must declare the function as returning SETOF record when there are multiple output parameters, or SETOF sometype when there is just one output parameter of type sometype, in order to create a set-returning function with output parameters. Т.е. в первом случае должно быть returns setof text.

спасибо!

если надо разделять запросы прозрачно для клиента, то это умеет pgpool например. Pgbouncer не умеет и он не для этого

Надо как раз разделить запросы прозрачно для клиента. Как это сделать с pgpool?

это не ко мне

привет есть таблица пользователь и у нее есть колонка Type. Значение True/False В зависимости от Type, надо сделать join одной или другой таблицы. Как это записать?

привет есть таблица пользователь и у нее есть колонка Type. Значение True/False В зависимости от Type, надо сделать join одной или другой таблицы. Как это записать?

LEFT JOIN, скорее всего.

users LEFT join type1.user_id = users.id

не понимаю

не понимаю

Я имел в виду что-то вроде: SELECT * FROM users LEFT JOIN table1 ON users.type AND table1.a = users.b LEFT JOIN table2 ON NOT users.type AND table2.c = users.d;

спасибо, попробую

насколько критично вот такую штуку использовать в продакшене? https://github.com/smashedtoatoms/asdf-postgres

Зачем вообще использовать менеджеры версий в продакшене?

Зачем вообще использовать менеджеры версий в продакшене?

хороший вопрос, но вообще-то ищу альтернативу докеру, для быстрого развертывания

А в чем с контейнерами проблема?

точнее, в чём проблема с докером?

Коллеги, привет! Подскажите, почему на асинхронной реплике при селекте могу получать такую ошибку ОШИБКА: не удалось прочитать блок 0 в файле "base/16397/2255745" (прочитано байт: 0 из 8192) На мастере все ок. Ищу по определенному полю. Если искать по другому полю, то ошибку не получаю.