Я думал мы уже пережили средневековье, когда на всё воля Господа и вылеченным считается живая особь... Но Oracle, видимо, считает иначе... Олсо, я где-то слышал, что постгря потихоньку отбирает сладости у ВЕЛИКОГО.

Факт, но много не хватает! Не хватает хинтов как минимум

хинтов?

зачем?

Материализация

что "материализация"?

надо материализовать - пишешь СTE и радуешься :)

скажу еще чего сильно не хватает - хорошего мониторинга ожиданий сессии (как у оракла)

а то что рассказывали на highload довольно скудно

многие хинты интересны... ordered, parallel...

какой запрос надо ими исправить?

некоторые запросы на табличке в 500М+ записей некорректно обрабатываются оптимизатором

parallell это пока не про postgres вообще

покажи запрос :)

я и говорю - не хватает мне их ))))

это издевательство - там запрос листов на 10 формата А4

всегда можно усечь :)

что мне ещё не хватает? автономных транзакций, пакетов

пакетов +1

автономных транзакций +1

Вообще я не очень силён в PostgreSQL, но как минимум меня взбесило - что я создал пользователя, дал ему права CONNECT, EXECUTE на выбранные функции, а он может получить список всех функций и их исходный код

ну правильно, только connect и execute

Может и правильно, а что он может посмотреть структуру всех объектов, текст всех функций - не гут совсем

@iWisenheimer всех функций в своей схеме? или во всей субд?

тут рассылка OpenStreetMap принесла https://github.com/rory/pgindexrebuild

во всей субд

pg_proc сдаёт

сама организация больше напоминает MS SQL/Sybase если честно в этом вопросе...

В логе postgresql 9.3.4 1C. Вижу следующие сообщения: No left sibling (concurrent deletion?) in "pg_attribute_relid_attnum_index", No left sibling (concurrent deletion?) in "pg_attribute_relid_attnam_index". Стоит беспокоиться об этом ?

https://telegram.me/PostgreSQL_1C_Linux

Эти сообщения не относятся к 1С.

CharybdeFS - клевая fuse-fs для проверки "как будет себя вести под нагрузкой, что будет если диск начнет сбоить и тд и тп"

Есть БД в которой несколько таблиц без oid. По этой таблицице был сделан truncate, в результате чего в pg_largeobjects осталось какое-то количество данных... Вопрос: как их грамотно удалить? vacuumlo не предлагать. Он херит данные с соответствующих полях рабочих таблиц.

рестартнуть для allow_system_table_mods нельзя?

Есть бд с mysql. В ней для представление boolean типов использовался tinyint. Перевел с помощью NMIG бд в postgresql. Запускаю приложение - получаю ошибку: org.postgresql.util.PSQLException: ОШИБКА: оператор не существует: smallint = boolean Подсказка: Оператор с данными именем и типами аргументов не найден. Возможно, вам следует добавить явные приведения типов. Посоветуете лучшее решение? (p.s. smallint -> boolean используется по всему приложению)

ну либо создайте оператор, либо явно приводите в запросе smallint к boolean или наоборот

ALTER TABLE sdo_answers ALTER COLUMN correct DROP DEFAULT, ALTER COLUMN correct TYPE BOOL USING CASE WHEN correct = 0 THEN FALSE ELSE TRUE END, ALTER COLUMN correct SET DEFAULT FALSE;

в итоге сделал, спасибо.

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

рестартнуть для allow_system_table_mods нельзя?

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

Попробовал (на тесте из бэкапа восстановил), как предлагают сдесь: http://stackoverflow.com/questions/5625585/sql-postgres-oids-what-are-they-and-why-are-they-useful Запрос выдал Out of Shared Memory: max_locks_per_transaction. Параметр установлен в 1024. По идее достаточно. Размер pg_largeobject 20Гб

А есть какая-либо тулза, в который акромя прочего можно было бы посмотреть slow query?

А есть какая-либо тулза, в который акромя прочего можно было бы посмотреть slow query?

pg_stat_statements

Спасибо, то что нужно.

0_o что за ... ?

Боты похоже

Да, у меня такая же картина.

ну и что?

Это законченная сентенция. И всё.

нахуя они это делают только

Спам, насос пипла в рекламные группы, спамовая реклама за копейки.

либо статистика по чатам

С таким-то именем у робота?

Статистику у чата можно собирать не только через tg-cli, для этого bot API хватает до усеру.

а нет чего-то аля капчи?

Можно сделать только по инвайтам

Но это беспредел

Статистику у чата можно собирать не только через tg-cli, для этого bot API хватает до усеру.

истоию нельзя

Добрый день. Стоит postgres 9.3.4. В логах postgresql начали появляться ошибки вида "failed to re-find parent key in index pg_class_oid_index for deletion target". Сыпятся каждую минуту. После переадресации пропадают, но позже(прошло 2 дня с предыдущего инцидента) опять появляются. С чем это может быть связано? Куда вообще копать и не завалятся ли при этом данные?

Насколько я понял, ошибка появляется при попытке автовакуума потрогать таблицы.

Добрый день. Стоит postgres 9.3.4. В логах postgresql начали появляться ошибки вида "failed to re-find parent key in index pg_class_oid_index for deletion target". Сыпятся каждую минуту. После переадресации пропадают, но позже(прошло 2 дня с предыдущего инцидента) опять появляются. С чем это может быть связано? Куда вообще копать и не завалятся ли при этом данные?

что за переадресация? это перестроение индекса? на разных индексах новые ошибки?

что за переадресация? это перестроение индекса? на разных индексах новые ошибки?

Прошу прощения. Переиндексации. Писал утром с телефона.

а новая ошибка через 2 дня на другом и индексе?

Да, на другом. Но я делал полную переиндексацию для бд. Т.е. должен был перестроить все.

перестроить

--data-checksums включено при инициализации кластера? стоило бы через pg_dump проверить целостность данных

Да, разумеется перестроить.

Чексуммы не включены. Pg_dump базу выгружает.

Уже встречался с крышем базы. Pg_dump падал без вариантов. Сейчас отрабатывает без проблем.

Не понятным моментом остается ситуация с прочей индексов.

а в разных ошибках там вместо pg_class_oid_index , другое имя индекса?

это системный pg_catalog, reindex пользовательских индексов на него не влияет думаю

REINDEX DATABASE делался?

Так же были pg_attribute_relid_attnam_index и pg_depend_depender_index

Я понимаю что это системные

Тем не менее, прогон reindexdb -d database_name приводит к тому что ошибки перестают сыпаться каждую минуту в лог.

а баз несколько на серваке?

Несколько.

Есть тестовые базы и рабочие. Ошибки сыпались на одной рабочей и одной очень древней тестовой. И ту и другую переиндексировал. Лог становится чистым. Сегодня ситуация повторилась. Опять reindexdb по ним и опять чистый лог. Снимать лампы pg_dump`ом пробовал - отрабатывают. В лог сервера ошибок о неудаче не спамят и разворачиваются во другие базы так же без ошибок.

ну вариант что 2 дня не использовалось обращение к индексу где ошибка наверно врядли это, значит ошибка заного появилась, может там диски проверить?

DATABASE Перестраивает все индексы в текущей базе данных. При этом обрабатываются также индексы в общих системных каталогах. Эту форму REINDEX нельзя выполнить в блоке транзакции. SYSTEM Перестраивает все индексы в системных каталогах текущей базы данных. При этом обрабатываются также индексы в общих системных каталогах, но индексы в таблицах пользователя не затрагиваются. Эту форму REINDEX нельзя выполнить в блоке транзакции.

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

есть какие то общие системные каталогии и у каждой базы отдельные видимо

но все равно шанс что что не проиндексировал мал вроде

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