Да я вот этим и занят... там просто "императивщины" хватает

Просто пока это больше "на авось" похоже

Чего кстати pgday пропустили ?

а записи докладов с этого pgday будут?

только презентации

тогда хорошо что не поехал и не спонсировал таких жмотов. С прошлого были.

Хороший

))

Добрый день. Имеется postgresql 9.3.4. Решил организовать горячие бэкапы. Установил wal_level hot_standby, прописал архивные команды, запустился, сделал базовый бэкап через pg_basebackup. Все отработало без ошибок, но при подключении к бд увидел картину маслом - колличество таблиц в базах удвоилось. Вместо 5000 стало 10000. Откатился назад и все восстановил, остался вопрос в чем собственно проблема? Из-за чего появился такой артефакт?

А вы не смотрели, что это были за таблицы?

Все рабочие таблицы

С теми же самыми именами. Что вдвойне странно.

Т.е. К приему, две таблицы users.

Чем смотрели? У меня было так с PGAdmin-ом.

psql все правильно показывал и это было, как раз на 9.3

Смотрел действительно через pgadmin, и я мог бы это списать на его глюки, если бы не возникшие ошибки в клиентском приложении. Типа type already exist. Которые появились вместе с этим. И исчезли после отката. При этом никто не работал с базами.

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

такие ошибки действительно встречаются в pgadmin-е при отображении объектов бд. у нас была похожая проблема с дублированием полей таблиц. я пытался что-то поправить, но разработчики pgadmin-а уже полностью отказались от поддержки третьей версии. опять же - всегда можно форкнуть и show will go on)

а будет 4ая версия? или ничего не будет?

уже есть

beta2

https://www.pgadmin.org/docs4/dev/index.html

Это ошибка отображения? Или все же портятся сами базы? Как я сказал выше появились еще артефакты со стороны внешних приложений использующих базу на тот момент времени.

Причем дублировались не поля таблиц, а сами таблицы.

Это ошибка отображения? Или все же портятся сами базы? Как я сказал выше появились еще артефакты со стороны внешних приложений использующих базу на тот момент времени.

Можно же в psql посмотреть.

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

звучит дико. Думаю пока не воспроизведете ситуацию и не покажете что при этом происходит в psql тут люди просто не поверят

и буду считать, что это какое-то совпадение и ваши домыслы

нет, я поверю, что это ошибка отображения pgadmin-а)

сейчас не в pgadmin впрос, как я понял

с этим все понятно

Я сам понимаю что это все звучит дико. Был дико удивлен. Беглый поиск не дал результатов о такой проблеме. Поэтому задал вопрос тут. На днях попробую повторить действия еще раз.

День добрый! Я правильно понял из документации. что в общем случае не нужно править параметры ядра для работы сервера? https://postgrespro.ru/doc/kernel-resources.html

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

Угу

А это. Версия для 1с линуксовая при установке тюнит сама себя, как виндовая или нет?

неа :(

есть mamonsu tune

оно дает generic рекомендации

которые пойдут в 80% случаев

Надо мамона ставить?

Сейчас попробую

Надо мамона ставить?

там сейчас будет скоро новая версия под windows с инсталлером, который ты тестил

Это есть хорошо. Только Одно но - шеф закомандовал поднимать на убунте %)

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

Поскольку старую машину не загасил - потестю мамона.

Что с Юбунтой новой? Постгрес убивает?

Курение убивает

Убунта 14.04 - полёт нормальный

16 не пробовал

норм все

на 16.04 х64

Я там выше про автокомплит писал, так вот, на Ubuntu 14.04 в psql из комплекта 9.4.8 1c он работает.

Я там выше про автокомплит писал, так вот, на Ubuntu 14.04 в psql из комплекта 9.4.8 1c он работает.

Ну так там readline есть...

Есть

Есть у кого соображения на тему такой проблемы: Две полонстью одинаковые по настройке БД 9.5.2 (далее src и dst) В них созданы две абсолютно одинаковые таблицы и они реплицируются с использованием pglogical. В src идет insert (обновлений практически нет). С dst ничего кроме чтения не делается. так вот размеры таблиц отличаются почти в 2 раза (dst в больше src) src: psql (9.5.2) Type "help" for help. xdray=# \dt+ transactions_p2016_07_12 List of relations Schema | Name | Type | Owner | Size | Description —------+--------------------------+-------+-------+---------+------------- xdray | transactions_p2016_07_12 | table | xdray | 7956 MB | (1 row) dst: psql (9.5.2) Type "help" for help. xdray=# \dt+ transactions_p2016_07_12 List of relations Schema | Name | Type | Owner | Size | Description —------+--------------------------+-------+-------+-------+------------- xdray | transactions_p2016_07_12 | table | xdray | 13 GB | (1 row)

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

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

******

кто-то запалил свой суперсекурный пароль? :)

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

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

попробовал прогнать вручную vaccum размер не изменился (прогонял с ключем FREES)

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

http://dba.stackexchange.com/a/35816/58542

ERROR: S client not available

кхм, глупо, но всё же: количество записей сравнивали?

сравнил все ок

в общем помог только vacuum full

интересно почему при репликации она так пухнет...

есть подозрение конечно

думал что вот эти кейсы: CONFLICT: remote UPDATE on relation xdray.transactions_p2016_07_07. Resolution: apply_remote.

но их реально единицы на неделю

не могли же они так накачать...

нда... интересный феномен

вот есть какое-то обсуждение на подобную тему, не вникала, но мб найдёте что-то интересное по приведённым ссылкам: https://www.postgresql.org/message-id/5421822D.8@aklaver.com

ну там про физический стендбай

тут чутка иное

¯\_(ツ)_/¯ я пыталась )

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

если он был запущенный — то скажет, что уже запущен, всё.

то есть база не побьется ? (ну кроме какой то части данных)

а зачем вам это?

возмжно при малой (отсутсвующей) активности во время копирования может повезти

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

но делать это намеренно не понятно зачем

нет

просто эфемерный вопрос.

а, эфемерный вопрос — эфемерный ответ.

то есть база не побьется ? (ну кроме какой то части данных)

Наверное.

если хочется убить консистентность базы - есть другие более быстрые способы

=)

консистентность в данном случае не сильно критична

господа, а вообще repmgr повзоялет сделать так что бы перевод мастера был бесшовный ?

а то у меня получается что процедура каждый раз примерно такая http://pastie.org/private/bxm8jbtgwsmntttnnf2mq

не разу еще не удалось сделать так что бы standby follow сработал ровно

я пгпул настроил, но тоже не идеальное решение