PGSql падает в сегфолт при ALTER TABLE

Лучше всего выложить логи.

На вскидку: может быть какие-то проблемы с правами пользователя или самого постгреса, не позволяющие ему это делать. Или раздел забит под завязку. См. команду df.

Место есть, права полные на всю схему есть. В логах просто сегфолт после запроса:

ALTER TABLE users ALTER COLUMN online SET DATA TYPE timestamp without time zone USING to_timestamp(online)::timestamp without time zone;

к слову REINDEX TABLE роняет в такой же segfault

ОЗУ сколько? В процессе работы растет и если растет то на сколько?

В dmesg что-то есть?

ОЗУ сколько? В процессе работы растет и если растет то на сколько?

8 GB. Пиков нет.

В dmesg что-то есть?

В dmesg'е ничего свежего нет - последние записи совсем старые.

Попробуй запустить под gdb и посмотреть где падает. И установить дебажные пакеты или собрать с дебаг-символами.

Дебажные/вербозные логи можно включить?

strace что говорит?

REINDEX TABLE роняет в такой же segfault

Просто в качестве бредовых идей а-ля мозговой штурм: если с местом на диске и с правами postgresql (а так же пользователя бд) всё Ok, то, м. б., битый диск (как раз те блоки, где лежит БД) или неправильная БД (что-то не то с индексами etc). Проверить можно, проверив ф/с и поверхность диска и экспортировав и снова импортировав БД.

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

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

dd conv=noerror ?

с непойми чем в базе

Тогда тем более надо попытаться корректно экспортировать (если получится), потом на всякий случай вообще всё удалить и снова импортировать. А если экспортировать не получится... Тогда хотя бы то, что удастся.

-> mysql

Посмотри стектрейс в кордампе для начала.

Посмотри стектрейс в кордампе для начала.

Деление на ноль при попытке аллокации памяти.

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