Fwd_oracle искали?

foreign data wrapper вроде не дает вызвать функцию

только таблички, емнип

Добрый день. Можно ли организовать вызов оракловой функции средствами postgres? Т.е. установить связь с ораклом со стороны постгреса и вызвать функцию?

Наверное можно попробовать вызвать хранимку через ODBC вот тут мануал был - как подключать http://raghavt.blogspot.ru/2016/05/ways-to-access-oracle-database-in.html

Срочно в эфир: https://www.postgresql.org/about/news/1717/

Amazon RDS now supports PostgreSQL 9.6.1

только таблички, емнип

Все верно. oracle_fdw использую для доступа к таблица/обзорам. Функцию там не вызвать.

а нельзя сделать такое view, которое дёрнет функцию?

Amazon RDS now supports PostgreSQL 9.6.1

Ага, DBA больше не нужны ? Спокойно, уже ухожу ??

да ладно, на RDS по умолчанию work_mem в 4 mb

умеешь крутить work_mem на rds и знаешь, что это надо делать - нужный dba

а нельзя сделать такое view, которое дёрнет функцию?

Нужно параметры уметь передать таким образом.

insert into таблица, select from view

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

Ага, DBA больше не нужны ? Спокойно, уже ухожу ??

а амазон? ;)

Всем привет. Решил тут познакомится с постгресом и сделать на нем не большой проектик для себя любимого. Но вот расстройство. Постаивл я значит postgresql 9.6 + pgadmin 4 Создал в нем базу, таблицу, столбцы. Патюсь через query tool отправить пару insert. А вместо результата получаю "Not connected to the server or the connection to the server has been closed." При этом тут же делаю селект к таблице - и все нормльно. пробовал гуглить - и ничего путного не нашел. Подскажите в чем может быть проблема?

В пгадмин4

пичаль. а как починить?

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

Это конечно мог бы быть вариант, но такой сервис может использовать одновременно много людей. Можно конечно поизвращаться с разбиением данных в таблице по пользователям. Но может есть более нативный вариант. Сильно сложные вещи городить не хотелось бы по двум причинам: вызываться это все должно встроенными мезанизмами 1с(а там уже можно словить кучу ограничений); не хотелось бы быть сильно прикладываться к реализации оракловой. Там другие люди за это отвечают и хотелось бы просто использовать их функцию как черный ящик. Без дополнительных телодвижений.

пичаль. а как починить?

Поставить пгадмин3 :)

так все плохо?

Пока что да

ок. пойду качать третий.

а внешне такой симпотичный был...

а багу в трекер завели?

а то вот это "оно нехорошее, пользуйтесь другим" без попытки пропатчить / сообщить о проблеме, обычно приводит к загниванию экосистемы

https://www.bigsql.org/pgadmin3

а багу в трекер завели?

багу -то я заведу. Но согласитесь странная такая бага.

Какие запросы проходят, а какие-то нет

причем ни какой магии написать-то не успел.

странная, да

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

поэтому и грешил больше на свои кривые руки, чем на тулзу.

Поставить пгадмин3 :)

таки помогло. спасибо.

таки помогло. спасибо.

не за что

Коллеги, помогите найти виновника торжества. Есть таблица, в которой 9432 строки. Обычный размер с индексами около 7Мб. Таблица распухает на глазах. Раньше помогал vacuum full, но сейчас (возможно изза нового релиза) vacuum full ее не может почистить и не могу найти кто держит строки: postgres=# SELECT relation::regclass, * FROM pg_locks where relation::regclass::text like '%mobileitm%'; relation | locktype | database | relation | page | tuple | virtualxid | transactionid | classid | objid | objsubid | virtualtransaction | pid | mode | granted | fastpath ----------+----------+----------+----------+------+-------+------------+---------------+---------+-------+----------+--------------------+-----+------+---------+---------- (0 rows)   postgres=# vacuum full verbose mobileitm; INFO:  vacuuming "gkmobile.as_itm" INFO:  "mobileitm": found 0 removable, 914904 nonremovable row versions in 62482 pages DETAIL:  905472 dead row versions cannot be removed yet. CPU 1.70s/10.58u sec elapsed 25.11 sec. VACUUM postgres=#  select pg_size_pretty( pg_total_relation_size('mobileitm') ); pg_size_pretty ---------------- 686 MB (1 row) Как найти кто держит?

Репликация есть?

Нет

сделай ей cluster по какому-нибудь индексу, если её можно полочить на некоторое время

Сделаю, но т.к. ее размер вырос почти в 100 раз придётся ночью. Есть ли способ понять/узнать кто держит?? В pg_locks ничего нет. Чекпоинты каждые 10 минут , не думаю что это из-за wal.. При этом рестарт приложения без рестарта субд помогает и vacuum full проходит.

Idle connect

Idle in transaction есть (появились с последним релизом), но коннекции к другой схеме(той же бд). Разве в pg_locks их быть не должно?

Нет

Т.e. все idle соединения держат какие то строк в таблице? Какой корректный способ поведения для пула, чтобы предотвратить разбухание таблиц и иметь возможность выполнять vacuum full? Каждый раз полностью закрывать соединение?

Закрывать транзакции

Держат только idle in transaction

Так, но те запросы которые висят в idle in transaction они к другой схеме и то что они лочат таблицы видно в pg_locks. Этой же таблицы нет.

Т.e. все idle соединения держат какие то строк в таблице? Какой корректный способ поведения для пула, чтобы предотвратить разбухание таблиц и иметь возможность выполнять vacuum full? Каждый раз полностью закрывать соединение?

у вас там celery_beat ? или что похожее?

Нет, 2 java приложения. Какой фреймвор для пула используется с ходу не скажу...

А это не механизм явных локов, а MVCC

Я понимаю что это mvcc, но для него же все равно нужен наверное лок... иначе как vacuum понимает, что эти строки еще нужны.

Так, но те запросы которые висят в idle in transaction они к другой схеме и то что они лочат таблицы видно в pg_locks. Этой же таблицы нет.

у вас залип xmin, это происходит по нескольким причинам: 1) залип xmin в каком-либо слоте репликации (pg_replication_slots), 2) есть какая(ие)-то незавершенные транзакции, которые еще выполняются со снапшотом, в котором этот xmin, т.е. они с их снапшотом еще могут видеть те строки, которые вакуум хочет вычистить. Смотреть в pg_stat_activity WHERE state <> 'idle' order by xact_start ну и автовакуум не считать, или есть prepared xacts select * from pg_prepared_xacts

Спасибо, забыл про prepared, а это может быть...

Круто, в арч завезли 9.6, а постгис для него - нет

ну вы бы ещё более странный дистр нашли

честно говоря, не видел опций "сервер на арче" нигде

ну есть любители

всё апдейтить и патчить

апдейтить и патчить - арч не нужен

ну вы бы ещё более странный дистр нашли

На самом деле для десктопа - очень даже хороший дистр. Пробовал использовать на сервере - не то. Слишком часто пакеты обновляются и ядро. Даже в LTS )

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

Круто, в арч завезли 9.6, а постгис для него - нет

почему арч?

@cantrell а 2.3 не совместимо с 9.6?

бинарно? :)

ERROR: S client not available

2.3 от 2.5 - вряд ли :)

@cantrell а 2.3 не совместимо с 9.6?

он собран под 9.5

почему арч?

На десктопе его гоняю, разрабатываю в нем же

Ребят, у кого-нибудь был случай с загрузкой логов в pg

некоторых полей иногда может не быть

и он не ковертирует их в null почему-то

не консистентно получается

Конвертирует в zero-length string?

null '' указан?

коллеги, а каких тут привилегий не хватает: staging=> alter database staging set logidze.disabled TO off; ERROR: permission denied to set parameter "logidze.disabled"

?

пользователь, от которого запускается, является овнером базы staging

Only the database owner or a superuser can change the session defaults for a database. Certain variables cannot be set this way, or can only be set by a superuser.

ну видимо твой параметр овнер не может

да, пришлось-таки делать суперюзером, гнать миграцию, отнимать суперюзера

Ребят , вопрос. Для materialized view, основанной на большой таблице. Во время выполнения команды refresh - старые данные доступны во время обновления или они стразу удаляются?

Ребят , вопрос. Для materialized view, основанной на большой таблице. Во время выполнения команды refresh - старые данные доступны во время обновления или они стразу удаляются?

Доступны. И лучше делайте CONCURRENTLY

спасибо!

спасибо!

не за что. Не забудьте только добавить индекс UNIQUE

на ключ который транслируется в MV?

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

правильно понимаю, что если в оригинальной таблице есть PK, то мы в MV должны создать unique index по этому полю (полям)?

в mv у тебя может быть любой PK или не быть

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

понял

Доступны. И лучше делайте CONCURRENTLY

Вадим, во время тестов с refresh materialized view получилось что во время обновления данные блокируются до конца обновления

Вадим, во время тестов с refresh materialized view получилось что во время обновления данные блокируются до конца обновления

вы делали refresh materialized view my_view CONCURRENTLY ?

Мой недосмотр. Без него.

с ним будет работать. Запрос должен иметь вид REFRESH MATERIALIZED VIEW CONCURRENTLY my_view.

с ним будет работать. Запрос должен иметь вид REFRESH MATERIALIZED VIEW CONCURRENTLY my_view.

Все сработало. Вадим спасибо.

не за что