Мой дорогой беспланый Постгрес сапорт )) помогите пожалуйста, как можно отловить причину “Caused by: org.postgresql.util.PSQLException: An I/O error occurred while sending to the backend.” это со стороны сервера приложений, в базе запись дисконнекта появляется .. вызов функции напрямую в базу отрабатывает без ошибок, со стороны приклада вот такая хрень идет =\ остальной функционал работает корректно

А unlogged таблицы внутри не используются?

момент

спасибы

а, стопэ

а, не, всё норм)

ещё раз спасибо)

А unlogged таблицы внутри не используются?

http://paste.org.ru/?w9a979 не, никакой магии нет

Я встречал эту ошибку, но не помню при каких обстоятельствах. Попробуйте проверить коннекты с приложения, проверить что таблицы не залочены и всё в этом духе, мб отреливается по таймауту.

Юрий , спасибо!

Юрий ошибся. Лицензия приведена на сайте

т.е таки платный ?

"for any purpose, without fee”

точно ..

т.е. если вы скачиваете бинарную сборку, то именно там и уточнайте лицензию, там я могу не знать.

Я ничем бинарным не пользуюсь и вообще на gentoo сижу :)

))))))) олд скул

всем привет, кто-нибудь пользуется citext? заметно ли повысит производительность? сижу вот думаю стоит ли вообще экспериментировать с этим делом

Мне кажется citext вынужденная мера

Коллеги привет! У себя заменил два коммутатора (стало не хватать портов) теперь без дела лежат две Cisco WS-C3750G-24T-S, может нужны кому? Работали в стеке. Кабеля прилагаются. Отдам по 20.000 р за каждый.

Давайте в 12 голосом

согласна

Давайте в 12 голосом

Окошком ошиблись?

Окошком ошиблись?

Соури ошибся

Привет, ребята! Не подскажете какой тулзой пользуетесь при миграции с Mysql на PostgreSQL.

https://github.com/AnatolyUss/FromMySqlToPostgreSql - у меня не взлетело

вродеб ora2pg начала поддерживать такую миграцию

http://ora2pg.darold.net/

Спасибо!

Добрый день. Сегодня ночью начал ловить сообщения вида «failed to re-find parent key in index "pg_class_oid_index" for deletion target».решил восстановить с последней базовой копии. Все wals скормил , запустился - та же ошибка. Восстановился еще раз до момента ее появления в логах. Пока больше не вылезает. В чем может быть причина? И почему проигрывание wal воспроизводит ее.? Использую PostgreSQL 9.4.9 1C от PostgresPro.

Если других бакапов нет - то pg_dump + initdb. Что за дистрибутив Linux?

наверное pg_dumpall

кстати, как забекапить базу полностью, со всем установленными экстеншнами?

на случай если сервер полностью умер - пошел дым, мы на новом устанавливаем postgres, делаем initdb, потом заливаем все, что было из pg_dumpall

а вот экстеншны нет

в итоге залить получится с ошибками

того же hstore нет и привет

никто не сталкивался?

кстати, как забекапить базу полностью, со всем установленными экстеншнами?

pg_dump бекапит включением в дамп команды CREATE EXTENSION. А если у Вас на свежеподнятом серваке каталог <path2install>/extension пуст или его вообще нет - ну тады ой.

а если использовать pg_dumpall?

А какая разница? содержимое указанного каталога принадлежит установленному ПО, а не данным. Сейчас проверил - ситуация аналогичная CREATE EXTENSION - и усё.

Сенкс!!!

--exit-on-error для restore + ON_ERROR_STOP psql

без этого "восстанавливаться" безсмысленно.

Есть способ заставить автовакуум перестать спамить в лог «autovacuum: found orphan temp table in database»?

Выполнил vacuum full по базе - не помогло.

я вам наверно месяц назад говорил :( перелейте в новый инстанс :(

Да эт новое уже :)

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

Насчет переливов я писал что не давно переливались.

Есть способ заставить автовакуум перестать спамить в лог «autovacuum: found orphan temp table in database»?

только дропнуть временные схемы и временные тост схемы

Сам постгрес это делать не умеет?

только при врапараунде

https://www.postgresql.org/message-id/flat/7b7f3e98-9753-3fa9-aaa4-b6f8a766c251%40postgrespro.ru#7b7f3e98-9753-3fa9-aaa4-b6f8a766c251@postgrespro.ru

мы пилим патч, который это поправит

Да, находил это.

*планируем запилить патч

Я думал что может ситуация с тех пор поменялась

за 24 дня - врядли =)

не дропайте временные схемы во время работы приложения!

ERROR: S client not available

это выбьет временные таблицы из-под ног у всех бэкендов

а что мешает дропнуть конкретную таблицу?

их там 100500

Я ошибся со ссылкой. Я видел другие подобные темы. Вашу - нет.

если это 1С

Все верно. :) под 1000

не дропайте временные схемы во время работы приложения!

Вы имеете ввиду что нужно остановить 1с перед этим? Автовакуум с ума не сойдет тоже от такого?

grep + psql, и хоть миллион

grep + psql, и хоть миллион

из pg_class кто удалит?

автовакуум перестанет сходить с ума как раз

из pg_class кто удалит?

Разве drop схемы не снесет из pg_class все лишнее?

заклинит с out of memory

нет-нет, drop schema нормально отработает

Брр, как так. Я видел много советов что это работает

CASCADE только не забудьте указать

Ну да.

Он тоасты соответствующие тоже почистит?

Или по ним тоже вручную пробегать

тоже вручную, к сожалению

Есть смысл чистить только те схемы что в лог попадают? Или можно на все замахнуться?

М.б. автовакуум еще до них не дошел.

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

*момент времени

блин, я так и не понял, почему не подходит drop table pg_temp_15.tt38147

открытая транзакция?

таблица же осталась после падения бэкенда?

можно и не дожидаться падения бэкенда =)

Поцоны, а подскажите за полнотекстовый поиск, а? Есть таблица, в ней под ФИО отдельный поля. Вот так строится вектор: UPDATE person SET ts = setweight( to_tsvector( 'simple', coalesce(person_lastname,'')),'A') || setweight( to_tsvector( 'simple', coalesce(person_firstname,'')),'B') || setweight( to_tsvector( 'simple', coalesce(person_midname,'')),'C'); В тблице есть две записи например, "Волков Александр Александрович" и "Волков Иван Александрович". При этом вот такой поисковый запрос дает одинаковые результующие веса для обоих записей: SELECT ts_rank(ts, 'волков:* & александр:* & александрович:*'::TSQUERY) FROM "person" WHERE (ts @@ 'волков:* & александр:* & александрович:*') Почему?

https://www.postgresql.org/docs/9.6/static/release-9-6.html