исходная ячейка, куда идёт запись выглдит так:
формат jsonb, внутри []

если кто-то знает, как освободить место, если на диске с базой уже 0 ?

или truncate, или в другой tablespace переносить на новый диск

не.. даже индексы нельзя удалить

Останавливать инстанс, переносить WAL-ы, в PGDATA делать симлинк на новое место.

разумно)

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

спс) а то я в панике сразу и не сообразил

видимо не только у меня админы профукивают триггеры

Разное бывает
Иногда разработка льет что-то лютое , что к фигам забивает всю базу
Около 40-50Г за 15-20 минут когда мы просто нет успевали отреагировать

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

А иногда и действительно можно проворонить триггер, особенно если в это время что-то другое чинишь )

Поэтому знать как действовать в любой возможной ситуации всегда полезно
Хотя в идеале конечно сделать все что предотвратить ее появление )

В моем случае помогало дёрнуть дежурного админа и расширить разделы по быстрому
Но случаи бывают разные ))

Добрый день. БД PostgreSQL 9.6 перешла в режим только для чтения из-за XID wraparound. Перешёл в режим single mode, maintenance work mem установил в 70Гб, workmem в 15Гб, ОЗУ на сервере 120Гб. Запустил Vacuum. Через 5 часов Vacuum завершился с ошибкой из за того, что индекс поврежден и нужно сделать Reindex. Запустил reindex всей БД с такими же параметрами конфига, он проработал сутки очень медленно и не известно когда закончится. Вопросы: можно ли удалить некоторые таблицы в single user режиме? Как оценить прогресс reindex и/или vacuum, вообще стоит ли этим заниматься или проще весь кластер пересоздать? Размер БД несколько ТБ.

> Vacuum завершился с ошибкой из за того, что индекс поврежден и нужно сделать Reindex

Какая конкретно была ошибка (там точно было написано про REINDEX, хотя бы)?
Остальное даже не имеет смысла обсуждать без ответа на этот вопрос.

Failed to re find parent key in index "index name" for deletion page NUMBER

Слова reindex не было

"failed to re-find tuple within index %s", может быть?
В общем, индекс-то "битый", что может намекать либо на то, что он был "криво" создан, либо на то, что этот кластер баз данных "битый", что гораздо хуже.

В первом случае можно попробовать сделать REINDEX именно этого индекса (т.е. прервать REINDEX всей БД — зачем Вы его вообще начали?).

А вот во втором случае нужно искать проблему с "железом" (скорее всего) и устранять её, и искать backup и восстанавливать из него, т.е. этот кластер выбросить.

Когда я принимал решение о REINDEX всей БД, я точно знал что VACUUM работает долго, и конечно, были мысли переиндексировать только этот индекс, но потом подумал также о том, что вдруг через N часов VACUUM наткнется на еще один поврежденный индекс. А оказывается REINDEX работает еще дольше чем VACUUM.

Если бы наткнулся — принимали бы решение снова.
Я не понимаю, почему Вы так относитесь к ошибкам, как будто это "пустяки, дело житейское"?
Если данные для Вас не имеют значения — DROP-нули бы этот индекс, или таблицу-другую — какая разница? ;)

На тот момент фактор времени был очень важен.

Так и вопрос: можно ли удалять таблицы, индексы в режиме read only или single user mode ?

Вопрос в том, что важнее — "фактор времени" или данные?
В single user mode можно удалять, конечно, почему нет?