Всем привет! В работе с пострес у меня опыта 2 месяца. После некорректного выключения наблюдаю такое 2018-03-03 16:31:03.958 +05 [18591] СООБЩЕНИЕ: автоочистка: найдена устаревшая врем. таблица "(null)"."tt34" в базе "sc3_kamin55_psql" 2018-03-03 16:31:03.958 +05 [18591] СООБЩЕНИЕ: автоочистка: найдена устаревшая врем. таблица "(null)"."tt35" в базе "sc3_kamin55_psql" если бы имя таблицы было, я бы мог удалить эту таблицу, но его нет, может кто поможет? Кому удобнее отвечать в веб можно написать сюда: https://www.linux.org.ru/forum/admin/14059386

Название _таблицы_ у Вас есть —- это "tt34" и т.п. А вот схема почему-то (null)... А Вы пробовали: DROP SCHEMA "(null)" CASCADE; ?

Я имея бекаб грохнул всю базу и пересоздал ее, сообщение ушло

сейчас наблюдаю такое 2018-03-03 17:36:29.902 +05 [637] ПРЕДУПРЕЖДЕНИЕ: заархивировать файл журнала транзакций "0000000100000006000000B6" не удалось много раз подряд; следующая попытка будет сделана позже 2018-03-03 17:37:29.966 +05 [637] СООБЩЕНИЕ: команда архивации завершилась ошибкой с кодом 1 2018-03-03 17:37:29.966 +05 [637] ПОДРОБНОСТИ: Команда архивации с ошибкой: test ! -f /Backup/WAL/0000000100000006000000B6 && cp pg_xlog/0000000100000006000000B6 /Backup/WAL/0000000100000006000000B6 2018-03-03 17:37:30.971 +05 [637] СООБЩЕНИЕ: команда архивации завершилась ошибкой с кодом 1 2018-03-03 17:37:30.971 +05 [637] ПОДРОБНОСТИ: Команда архивации с ошибкой: test ! -f /Backup/WAL/0000000100000006000000B6 && cp pg_xlog/0000000100000006000000B6 /Backup/WAL/0000000100000006000000B6 2018-03-03 17:37:31.975 +05 [637] СООБЩЕНИЕ: команда архивации завершилась ошибкой с кодом 1 2018-03-03 17:37:31.975 +05 [637] ПОДРОБНОСТИ: Команда архивации с ошибкой: test ! -f /Backup/WAL/0000000100000006000000B6 && cp pg_xlog/0000000100000006000000B6 /Backup/WAL/0000000100000006000000B6 2018-03-03 17:37:31.975 +05 [637] ПРЕДУПРЕЖДЕНИЕ: заархивировать файл журнала транзакций "0000000100000006000000B6" не удалось много раз подряд; следующая попытка будет сделана позже

то есть он один и тот же сегмент WAL мусолит по кругу и не может завершиться

судя по archive_command такой сегмент у тебя в архиве уже есть

ЭЭЭЭ )))) сейчас проверю

root@PostgreSQL:/home/maintainer# locate 0000000100000006000000B6 /databases/1CFresh/pg_xlog/0000000100000006000000B6 /databases/1CFresh/pg_xlog/archive_status/0000000100000006000000B6.ready

в пункте назначения его нет

проверь наличие файла: /Backup/WAL/0000000100000006000000B6

да, locate не работает для нелокальных систем, файл был, сейчас эта ошибка ушла

спс

всем привет

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

Можно

как это лучше сделать? прислать скриншот из workbenchа?

/spam

пацаны, а CREATE UNIQUE INDEX это DDL?

Да

Не DML точно

спасибо

Господа. У меня есть такая задача: есть набор различных источников данных. На вход подаются различные датасеты (не однократно, а периодически), которые нужно записывать и в дальнейшем предоставлять возможность сделать по выборке из нескольких разных датасетов создать новый. Что подойдет лучше для хранения такой модели данных: материализованные вьюшки (тут важно упомянуть: данные НЕ обновляются, на каждое обновление извне создается новый датасет), или же обычная динамическая генерация таблиц? То есть с генерацией таблиц я так или иначе столкнусь, но вопрос в том, где лучше хранить производные датасеты

Jsonb? Если они совсем уж произвольные

ой не хочется мне в это лезть

и там » 1000 полей может быть в одном элементе, так что лучше кмк все-таки на реляционной модели c таблицами/вью остановиться Просто в чем ништячность – все данные "плоские" (e.g. CSV)

Или топать в кликхауз )

А что за данные если не секрет?

А что за данные если не секрет?

Конкретно сейчас (не скажу откуда, ибо низя) выборки по определенным социологическим источникам в куче дико плохо оформленных сырых данных за пять лет, которые нужно к МЛ готовить.

но там задачка шире ставится, то есть сейчас это для демонстрации прототипа таск скорее, и отладки процессов + стека технологий.

а в чем разница между int и int()? работаю с mysql

https://t.me/mysql_ru

Битовые маски тогда может?

А уже из них генерить таблицы

в mysql конфе 520 мемберов, это значит что постгрес в 3 раза популярнее.

Тут люди отзывчивее в чате

в mysql конфе 520 мемберов, это значит что постгрес в 3 раза популярнее.

В математическом классе 20 мальчиков и 5 девочек. Это значит, что мальчики в 4 раза популярнее

В математическом классе 20 мальчиков и 5 девочек. Это значит, что мальчики в 4 раза популярнее

Ой как не толерантно. Но в целом да - это значит, что в математике соображает в 4 раза меньше девочек

В математическом классе 20 мальчиков и 5 девочек. Это значит, что мальчики в 4 раза популярнее

А можно и так сказать - что одной девочки в математике достаточно, а мальчиков нужно аж в 4 раза больше ))

Господа. У меня есть такая задача: есть набор различных источников данных. На вход подаются различные датасеты (не однократно, а периодически), которые нужно записывать и в дальнейшем предоставлять возможность сделать по выборке из нескольких разных датасетов создать новый. Что подойдет лучше для хранения такой модели данных: материализованные вьюшки (тут важно упомянуть: данные НЕ обновляются, на каждое обновление извне создается новый датасет), или же обычная динамическая генерация таблиц? То есть с генерацией таблиц я так или иначе столкнусь, но вопрос в том, где лучше хранить производные датасеты

Что дальше с этим зоопарком будет?

Господа. У меня есть такая задача: есть набор различных источников данных. На вход подаются различные датасеты (не однократно, а периодически), которые нужно записывать и в дальнейшем предоставлять возможность сделать по выборке из нескольких разных датасетов создать новый. Что подойдет лучше для хранения такой модели данных: материализованные вьюшки (тут важно упомянуть: данные НЕ обновляются, на каждое обновление извне создается новый датасет), или же обычная динамическая генерация таблиц? То есть с генерацией таблиц я так или иначе столкнусь, но вопрос в том, где лучше хранить производные датасеты

Если потом выборок много, то лучше динамически генерировать новые таблицы

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

Подскажите с чего лучше начать изучение Книги видео

Всем привет! В базе есть порядка 20-30 таблиц, и около 50 хранимых процедур, которые больше не используются (система переписывалась несколько раз разными разрабами). Вопрос: Как можно удалить эти таблицы и процедуры, не проводя анализ и удаление вручную?

Нужна волшебная кнопка «Сделать хорошо»

Подскажите с чего лучше начать изучение Книги видео

https://postgrespro.ru/education/courses

Всем привет! В базе есть порядка 20-30 таблиц, и около 50 хранимых процедур, которые больше не используются (система переписывалась несколько раз разными разрабами). Вопрос: Как можно удалить эти таблицы и процедуры, не проводя анализ и удаление вручную?

30+50 это совсем не много. за пару дней управитесь

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

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

Подход конечно верный и правильный, но на вопрос все-таки не отвечает. Вручную эти проверки делать не хочется. Хотел узнать нету ли какого-нибудь автоматизированного способа?!

Всем привет! Подскажите, а в каком процессе исполняются триггеры на таблицу? При этом усложню вопрос - есть логическая репликация, на таблице в базе подписчика есть триггер. Когда туда прилетают данные из декодированного вала от процесса подписки - какой процесс будет исполнять хранимку в триггере?

Подход конечно верный и правильный, но на вопрос все-таки не отвечает. Вручную эти проверки делать не хочется. Хотел узнать нету ли какого-нибудь автоматизированного способа?!

рассказываю как бы я на коленке такое "автоматизировал": получить список объектов для удаления (если еще нет), вставить во ВТОРОЙ столбец в экселе, в первом столбце написать DROP PROCEDURE или DROP TABLE , в третьем поставить ";", можно еще добавить кавычки в первый и третий, преобразовать в текст, скопировать в пгадмин, ..., ПРОФИТ

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

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

Вопрос был не "КАК УДАЛИТЬ ОДНИМ КЛИКОМ НЕСКОЛЬКО ТАБЛИЦ" , а как понять какие таблицы и процедуры используются и какие нет, не тратя время на разбор каждой таблицы и рысканий в коде.

Вопрос был не "КАК УДАЛИТЬ ОДНИМ КЛИКОМ НЕСКОЛЬКО ТАБЛИЦ" , а как понять какие таблицы и процедуры используются и какие нет, не тратя время на разбор каждой таблицы и рысканий в коде.

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

Вопрос был не "КАК УДАЛИТЬ ОДНИМ КЛИКОМ НЕСКОЛЬКО ТАБЛИЦ" , а как понять какие таблицы и процедуры используются и какие нет, не тратя время на разбор каждой таблицы и рысканий в коде.

Можно ответить только на вопрос «какие используются». Включить в лог запись запросов с длительностью 0, подождать и грепнуть. А кто не вошёл - анализировать, можно убить или нет

и еще раз 80 объектов это совсем не много. смелее :)

Можно ответить только на вопрос «какие используются». Включить в лог запись запросов с длительностью 0, подождать и грепнуть. А кто не вошёл - анализировать, можно убить или нет

сейчас Амир спросит "а как грепать-то?" ))

сейчас Амир спросит "а как грепать-то?" ))

Злой ты)

понедельник и не выспался (радио осм слушал до 3))

условно 10 лет как появилось русское сообщество openstreetmap

Можно ответить только на вопрос «какие используются». Включить в лог запись запросов с длительностью 0, подождать и грепнуть. А кто не вошёл - анализировать, можно убить или нет

Спасибо за идею, проверю

Спасибо за идею, проверю

Если стоит расширение pg_stat_statements, то можно сбросить его статистику и тоже подождать. Там накопятся запросы (даже грепать по логам не надо будет)

Хотя зачем сбрасывать)

Если стоит расширение pg_stat_statements, то можно сбросить его статистику и тоже подождать. Там накопятся запросы (даже грепать по логам не надо будет)

@adautov а пока ждете накопления статистики приводите в порядок руками ?

@adautov а пока ждете накопления статистики приводите в порядок руками ?

ну, пошел за перчатками тогда)

?

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

Бардак как раз легко автоматизируется. А вот порядок из бардака сложнее.

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

Добавляться не будут точно – требование к системе, а вот новые датасеты и датасеты-паразиты, появившиеся через обращения к старым точно будут.

Можно ответить только на вопрос «какие используются». Включить в лог запись запросов с длительностью 0, подождать и грепнуть. А кто не вошёл - анализировать, можно убить или нет

А ещё бывают вещи, которые вызываются по через крон раз в пятилетку... Не вижу я иного пути, кроме как грепать исходный код (ВЕСЬ!, включая кроны или как их там в винде называют) приложения.

А ещё бывают вещи, которые вызываются по через крон раз в пятилетку... Не вижу я иного пути, кроме как грепать исходный код (ВЕСЬ!, включая кроны или как их там в винде называют) приложения.

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

Всем привет! В базе есть порядка 20-30 таблиц, и около 50 хранимых процедур, которые больше не используются (система переписывалась несколько раз разными разрабами). Вопрос: Как можно удалить эти таблицы и процедуры, не проводя анализ и удаление вручную?

На Ваш вопрос единственный правильный ответ: НИКАК. Увы и ах. ЖЫзнь - боль и страдания, унижения и отчаяние.

Да, я - гуманист, клейма негде ставить. :D

может быть стоит попробовать собрать статистику по таблицам?

может быть стоит попробовать собрать статистику по таблицам?

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

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

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

Всем привет! Подскажите, а в каком процессе исполняются триггеры на таблицу? При этом усложню вопрос - есть логическая репликация, на таблице в базе подписчика есть триггер. Когда туда прилетают данные из декодированного вала от процесса подписки - какой процесс будет исполнять хранимку в триггере?

Если не ошибаюсь, триггер исполняется apply worker'ом. Тут еще немного про это есть https://www.postgresql.org/docs/10/static/logical-replication-architecture.html

Если не ошибаюсь, триггер исполняется apply worker'ом. Тут еще немного про это есть https://www.postgresql.org/docs/10/static/logical-replication-architecture.html

Спасибо! А сколько экземпляров apply worker порождается постмастером? Это настраивается?

По-моему есть максимум, он регулируется гуком max_logical_replication_workers

По-моему есть максимум, он регулируется гуком max_logical_replication_workers

О, отлично! Спасибо большое))

а так, количество apply worker'ов не меньше количеству подписчиков

вроде )

Я гляну в документации/исходниках. Но наводка шикарная

это не поможет. постгрес не умеет в параллельную репликацию ещё