Привет всем, какие права нужны чтоб COPY делать в файл, а не только в stdout?

Привет всем, какие права нужны чтоб COPY делать в файл, а не только в stdout?

В файл кажется только superuser писать может

Привет всем, какие права нужны чтоб COPY делать в файл, а не только в stdout?

“В таблице, данные которой читает команда COPY TO, требуется иметь право на выборку данных, а в таблице, куда вставляет значения COPY FROM, требуется право на добавление. При этом, если в команде перечисляются избранные столбцы, достаточно иметь права только для них. Если для таблицы включена защита на уровне строк, соответствующие политики SELECT будут применяться и к операторам COPY таблица TO. Операторы COPY FROM для таблиц с защитой строк в настоящее время не поддерживаются. Вместо них следует использовать равнозначные операторы INSERT. Файлы, указанные в команде COPY, читаются или записываются непосредственно сервером, не клиентским приложением. Поэтому они должны располагаться на сервере или быть доступными серверу, а не клиенту. Они должны быть доступны на чтение или запись пользователю Postgres Pro (пользователю, от имени которого работает сервер), не клиенту.” Excerpt From: The PostgreSQL Global Development Group. “Документация к Postgres Pro 9.6.2.1.” iBooks.

Привет всем! Есть таблица, на неё навешан after each row триггер для аудита событий. При вставках пакетом в десятки тысяч строк за раз выходит медленно от слова "очень" и триггер съедает 80% времени запроса. Вариант с переписыванием правил на вставку по производительности от after each row триггера не отличается. Есть ли какие варианты для ускорения? И да, можно ли исхитриться и в statement триггер по событию передать весь массив строк для вставки за один присест?

Отключить триггер и писать в аудит также пакетом

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

А в триггеры, которые after statement точно нет хитрой возможности что-то передать из пакетной вставки?

а точно медленно выходит т.е есть просто вставка 100тыс строк то 15с а с триггером 1500с ? или с триггером 30с ?

При 57тыс без триггера 9,5 сек, а с триггером - 49,5 сек

можно таблицы аудита делать unlogged если они используются только в экстренных случаях (ps тогда таблицы аудита не попадут в репликацию если такая имеется)

Нет, к сожалению они часть схемы и используются в хранимках((

меня все гложит идея попробовать для аудирования прикрутить механизм logical decoding

должно получиться достаточно дешево по ресурсам и надежно

Можно поподробнее, что такое logical deciding?

типа вот https://www.postgresql.org/docs/current/static/logicaldecoding-explanation.html

Все, я понял о чем вы. А в логическую репликации таблицы можно добавить пользователя, тип операции и время?

меня все гложит идея попробовать для аудирования прикрутить механизм logical decoding

Чем оно поможет для аудита?

ну по факту, ты делаешь изменения с объектом (таблицей) и хочешь зафиксировать "кто и какие изменения" сделал

вот "какие изменения" уже есть в WAL

и логикал декодинг может помочь асинхронно эту информацию сохранить в другое место

а вот по поводу "кто" - это да... пока вопрос на проработку

как первая идея, в оригинальной таблице должны быть поля типа "updated_at и updated_by"

единственно такой подход наверное не сработает при удалении...

Да, из неё удаляют (тоже пачками)

А выключение триггера транзакционно?

У меня есть мысль при вставках через хранимки выключить триггер в транзакции, самому пакетом записать данные в аудит и включить обратно

если включение/выключение тригера транзакционно, то при такой операции должна вешаться локировка на всю таблиц

или подразумевается, что в рамках других тразакций триггер все еще будет включен?

Да, в других транзакциях хотелось бы держать включённым. Так не работает, да?)

я утверждать не могу

Спасибо за советы, все равно

Всем привет. Что делать если выполнение pg_terminate_backend не отключает запрос?

То есть соединение не умирает? Можно из pg_stat_activity вытащить pid запроса и попробовать убить соединение через kill

То есть соединение не умирает? Можно из pg_stat_activity вытащить pid запроса и попробовать убить соединение через kill

Это в последнюю очередь надо делать. Если убить процесс, то база перейдёт в recovery mode.

Ну не надо убивать postmaster, убейте дочерний. Ведь именно это вы делаете через terminate backend. Если по-доброму, то нужно отменять запрос с сохранением соединения через cancel backend

да, вчера уже был переход в рекавери мод на пару минут, сегодня ситуация повторяется

Денис, даже дочерний процесс когда убиваете, база в рекавери переходит.

То есть соединение не умирает? Можно из pg_stat_activity вытащить pid запроса и попробовать убить соединение через kill

Боже, хватит уже убивать через kill. Есть же pg_cancel_backend(your_pid) и pg_terminate_backend(your_pid)

Если постмастер убить, то она вообще отрубится )

Боже, хватит уже убивать через kill. Есть же pg_cancel_backend(your_pid) и pg_terminate_backend(your_pid)

Так у ТС как раз эта функция и не работает, я так понял.

Может, PID неправильный?

проблема в том, что cancel_backend и terminate_backend выдают true, но запрос не отключается

Посмотрите, какой статус у процесса на сервере и как он расходует ресурсы.

процессор загружен практически до упора

pid из pg_stat_activity, так что вряд ли он неправильный

А strace можете к процессу подключиться? Что там происходит?

Процесс от приложения или системный? Со стороны приложения можно сказать, что происходит?

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

Всем привет. Что делать если выполнение pg_terminate_backend не отключает запрос?

еще актуально?

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

Всем привет. Подскажите, куда могло деться место на диске в pg (RDS), как посмотреть куда оно ушло? Если использовать запросы отсюда: https://wiki.postgresql.org/wiki/Disk_Usage то они показывают результаты будто у меня все ок

Но на самом деле у меня куда то пропало 25гб

При чем, пропало за 2 дня примерно. Понимание из-за чего примерно есть и я до сих пор не уверен, но проблема вроде локализована. Остался вопрос вернуть место бы

du не помогает чтоли?

Где я du то сделаю. У меня RDS

убить все сессии и vacuum?

Фул вакум сделал после теоретического отстрела проблемной части

Но место чет не особо вернулось

для начала мождно просто старые сессии прибить

я с RDS не знаком, на него нельзя подключиться psql?

psql можно

а с него нельзя \! du ?

А, я думал ты про $ du )

\! это ж локальная команда

На рдс так нельзя?

Блин короче нашел

ERROR: S client not available

Давным давно включил логгировние медленных запросов

Тогда их небыло вообще. Потом отвлекся и забыл

2 дня назад сделали деплой и посыпались

?

Коллеги, а кто-нибудь patroni ha cluster юзает?

Щас в консоли RDS нашел логи размером по гигабайту

На рдс так нельзя?

это не на удалённой машине выполнится, это прямо на той, на которой psql запущен же

На рдс нельзя по ссш?

Щас буду искать как логи снести оттуда

Нельзя

Блин как обычно через жопу удаляется с помощью их parameter groups

Через ретеншен ?

Коллеги, а кто-нибудь patroni ha cluster юзает?

Я

Я

Скажите, пожалуйста, patroni ведь не поддерживает кластер с несколькими hot standby?)

Конечно же поддерживает

Начто он тогда кластер

когда я делаю 4-х нодовый кластер, hot standby становится только одна нода

что-то ты путаешь

т.е.: 1. master 2 hot standby 3. replica

4. replica

не видел такого... Может быть у тебя в конфиге 2. указано notfailover

покажи patronictl list твой кластер

У тебя там не может быть написано master replica. Там только Leader и Sync Standby, если синхронная

в patroni.yml указано: tags: nofailover: false noloadbalance: false clonefrom: false nosync: false

Описал неправильно. Вывод: +---------+----------+----------+--------------+---------+-----------+ | Cluster | Member | Host | Role | State | Lag in MB | +---------+----------+----------+--------------+---------+-----------+ | pgsql | pgsql_01 | 10.0.0.2 | Leader | running | 0.0 | | pgsql | pgsql_02 | 10.0.0.3 | | running | 0.0 | | pgsql | pgsql_03 | 10.0.0.4 | Sync standby | running | 0.0 | | pgsql | pgsql_04 | 10.0.0.5 | | running | 0.0 | +---------+----------+----------+--------------+---------+-----------+

Ну все у тебя ок

Так вот, хочется, чтобы sync_standby было больше одного )

но в доке написано, что может быть только один

А, это да, не поддерживает

Вопрос: так будет всегда?)

Да, скорее всего да, почитай в issues на githab там подробно разжевано

спс)