По идее врапэраунд не должен случаться. Точно не помню, но по моему за 10 млн транзакций пг просто откажется принимать транзакции. 10 млн транзакций вполне достаточно, чтобы пофризить БД. Если есть ошибки врапэраунда, то скорее это будет означать, что БД сломалась, я так полагаю

По идее врапэраунд не должен случаться. Точно не помню, но по моему за 10 млн транзакций пг просто откажется принимать транзакции. 10 млн транзакций вполне достаточно, чтобы пофризить БД. Если есть ошибки врапэраунда, то скорее это будет означать, что БД сломалась, я так полагаю

Просто бд крашнулась при вакуме

Просто бд крашнулась при вакуме

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

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

у меня наверное - я от всех других ошибок избавился и даже утилиту накатал чтоб дергать целые записи, но xid wraparound просто на каждом тупле выскакивает в одной таблице. Думаю что можно вручную выставить последнюю tran id с помощью pg_resetxlog, но какой из параметров нужно шевелить для этого? -x ? https://www.postgresql.org/docs/9.5/static/app-pgresetxlog.html

Чувствую что придется таки пересобирать постгрес чтоб игнорить ошибку о wraparound

Может есть тут кто из postgrespro? Сколько может стоить дать вам поковыряться в сервере и сдампить целую дату на внешний диск, или хотя бы просто заставить бд сделать вакум? Датасет 4ТБ, нет возможности его перенести. Напишите в личку если не трудно.

Может есть тут кто из postgrespro? Сколько может стоить дать вам поковыряться в сервере и сдампить целую дату на внешний диск, или хотя бы просто заставить бд сделать вакум? Датасет 4ТБ, нет возможности его перенести. Напишите в личку если не трудно.

На фейсбуке продублируйте мессадж. Там быстрее ответят

Может есть тут кто из postgrespro? Сколько может стоить дать вам поковыряться в сервере и сдампить целую дату на внешний диск, или хотя бы просто заставить бд сделать вакум? Датасет 4ТБ, нет возможности его перенести. Напишите в личку если не трудно.

Напиши на info@postgrespro.ru

Ок спасиб

64-разрядный счетчик транзакций - это в следующих версиях такое будет, чтоб не нужно было делать вакум?

64-разрядный счетчик транзакций - это в следующих версиях такое будет, чтоб не нужно было делать вакум?

Вакуум нужно делать всегда.

64-разрядный счетчик транзакций - это в следующих версиях такое будет, чтоб не нужно было делать вакум?

останавливаться из-за вакуума не прийдеться.

А есть понимание во что проставить xid?

Тут вот описан способ

А есть понимание во что проставить xid?

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

habrahabr.ru/company/postgrespro/blog/301238

интересно еще найти способ вручную указывать xmin,xmax каждому туплу в коллекшоне

habrahabr.ru/company/postgrespro/blog/301238

спасибо. Мне что-то пришло озарение, что я на русском никогда не гуглил что-либо о постгре, только на английском

@vadvmkn делал

спасибо. Мне что-то пришло озарение, что я на русском никогда не гуглил что-либо о постгре, только на английском

Аналогично ?

А подскажите пожалуйста для Paxos готовые решения поверх rabbitmq с удобным UI для мониторинга

ыхыхы

А подскажите пожалуйста для Paxos готовые решения поверх rabbitmq с удобным UI для мониторинга

Это Вы что хотите сделать?

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

Хотелось бы иметь отдельный +1 сервис, который будет выполнять роль proposer

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

немного необычный дизайн системы. А поставить базу с общими данными в которую ходят микросервисы не вариант?

посмотрите в сторону riak

либо иную другую базу

У каждого микросервиса своя база сейчас

это плохо

:)

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

ЧТД )

Ага

не смущай товарища архитектора :)

Но так вышло

это плохо

А чем плохо?

Я встречал обратное - несколько сервисов ходят в одну базу и это плохо.

Я встречал обратное - несколько сервисов ходят в одну базу и это плохо.

чем плохо?

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

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

необходимостью ходить по ESB в разные сервисы и иногда по многу раз

А чем плохо?

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

А чем плохо?

+10 к сложности поддержки, +20 к проблемам рассинхрона данных

Так это значит проблема в том что надо несколько сервисов слить в один

Так как это одна логическая единица.

Так это значит проблема в том что надо несколько сервисов слить в один

стратегически - безусловно, это так :)

Так это значит проблема в том что надо несколько сервисов слить в один

не

Не всегда

Так это значит проблема в том что надо несколько сервисов слить в один

тсссс не раскрывай всех секретов сразу )

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

Сервисы должны быть самостоятельными и независимыми

Сервисы должны быть самостоятельными и независимыми

и не делать побочных эффектов в виде данных :)

Данные они могут делать, не связанные с другими сервисами

подскажите, плиз, а можно сделать distinct вместе с order и чтоб он делал distinct только по 1 полю, а не по всем :( ?

select distinct on (field) * order by field, field2;

но нюанс в том, что если дистинкт мне по id надо, а order по 2-ум другим полям

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

сделай подзапрос

??

хм

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

я похоже понял о чем речь, спасибо!)

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

только по-моему в оригинальной цитате говорится об уровне косвенности :)

А подскажите пожалуйста для Paxos готовые решения поверх rabbitmq с удобным UI для мониторинга

ЧЕГО

На хабре статейка свежая https://m.habrahabr.ru/company/postgrespro/blog/319770/ думаю по мотивам приключений с падением после вакуума.

Надеюсь не пригодится никогда

Утро доброе

Кто нибудь настаивал постгрес на винде для 1с? В частности интересует автовакуум на 9.3

Кто нибудь настаивал постгрес на винде для 1с? В частности интересует автовакуум на 9.3

@PostgreSQL_1C_Linux

Думаю, там лучше помогут

@PostgreSQL_1C_Linux

Спасибро

На хабре статейка свежая https://m.habrahabr.ru/company/postgrespro/blog/319770/ думаю по мотивам приключений с падением после вакуума.

Во-вторых, TOAST сейчас не поддерживается. Если строка хранится в несжатом виде или сжата на странице in-place, pg_filedump ее успешно восстановит (если сжатые данные не были испорчены). Однако если строка была перенесена во внешнюю TOAST-таблицу, вместо строки вы получите просто "(TOASTED)". В принципе, поддержка TOAST — не нерешаемая задача. Нужно только научить pg_filedump парсить каталог и находить соответствующую TOAST-таблицу. Просто пока что этого никто не сделал. Возможно, поддержка TOAST будет добавлена в будущих версиях pg_filedump.

привильно ли я понимаю, что если каталог остался живой, то возможно вытащить даные и из тоста?

@PostgreSQL_1C_Linux

там посылают сюда.. Ну что за народ

что там настраивать-то?

autovacuum = on

количество воркеров в зависимости от кол-ва ядер

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

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

и как это понять?

по возрасту datfrozenxid

смотреть статистику по insert, update delete

На хабре статейка свежая https://m.habrahabr.ru/company/postgrespro/blog/319770/ думаю по мотивам приключений с падением после вакуума.

ого круто то как

Добрый день! А команда REINDEX однопоточная?

https://postgrespro.ru/docs/postgresql/9.6/sql-reindex Однако заметьте, что REINDEX перестраивает индекс не в параллельном режиме

Вроде с 9.6 будет многопоточной

9.6 уже есть и там она не многопоточная

не надо демонизировать параллелизм в постгресе :)

чёт грозились сделать видимо отложили

кто и где грозился? :)

на какой то конфе, на видео говорили

значит на Postgres 10 будет (ну или будут обещать)

патч еще не вкоммитили, но есть

про параллел индекс билд