2 Funny_Falcon Поставили 8.2. Заработало. Т.е. пока вроде работает :-)

landy pavelvpНо я уже говорил выше - вместо QNX можно взять любую другую ОС. Кардинально ситуация не изменится, к сожалению... Предлагаю тему QNX больше не поднимать.

Еще раз Ну если вы так хотите, то давайте ещё раз. Только не устрайивайте больше ликбеза, ок? IMHO у нас опыта в этой области побольше вашего...Как Вы думаете для чего резервируют место под БД, скажем на примере Sybase, Oracle RDB ( просто Oracle тоже наверное , не знаю не работал), MS SQL и т п? Одна из задач - повышение производительности, другая - надежность. А PostgreSQL не может этого сделать? Религия запрещает?
При работе с зарезервированным местом не происходит расширения файлов и менеджер БД работает с местом на диске, которое никто другой не трогает(даже сама ОС), поэтому ошибок от краха файловой системы в момент расширения не присутствует в файлах БД, и возможно восстановиться до консистентного состояния.
При авариях в моменты расширения - вы этого не сделаете, т к у вас нет механизмов(имеется ввиду у менеджера БД) востановить файловую систему до консистентного состояния.
Поэтому все БД работающие со своими файлами как с файлами ОС подвержены таким крахам.
С НОРМАЛЬНЫМИ файловыми системами всё будет нормально. Если же говорить про файловую систему QNX, то там файл может гакнуться даже если никакого расширения не было. Достаточно чтобы он был открыт на запись - с большой вероятностью при аварии всё будет плохо (к тому же QNX работает в полном соответствии с POSIX и не делает ничего лишнего, проше говоря в некоторых случаях поведение может несколько не соответствовать привычно ожидаемому, хотя и в полном соответствии с POSIX). Так что может быть, и бывает, гораздо хуже чем Вы себе это представляете ;-)

У Postgres где-то в документации про это упоминается, сейчас никак не найду.
При добавлении или изменении данных в Postgres все время идет дозапись в конец файлов(за исключением WAL).
Ну это так - вкратце, а на самом деле все еще сложнее А на самом деле, например ЛИНТЕР, успешно работает на QNX в промышленных АСУТП.

PS Ещё раз предлагаю эту тему больше не поднимать.

Funny_FalconХорошо, на какой системе ещё (и с какими файловыми системамы) вы проводили killer тест? Да не помню я, на разных Linux.
К сожалению не могу провести killer test на своей тачке - все разделы под reiserfs. Или к чёрту. Щас запакую раздел, перегоню на другую тачку, переформачу, распакую .... Ждите ответа в следующей серии. Машина Sempron 2600+ s754 512 RAM винт 80 sata, по-моему WD. Мне кажется помимо возможных проблем ФС, поддают и алгоритмы восстановления БД при рестарте. Возможно это связано опять же с хранением версий в страницах данных, может какой-то баг в реализации WAL. Глубоко не ковыряли. Если в последних версиях всё у них хорошо, то это конечно же здорово.
Кстати, не советую 8.2.0 в продакшн. Там у них какие-то баги с сложными запросами вылезли.
Ну что делать, комунити не достаточно тестироваля. По этому поводу я и себя чуток виноватым чувствую.
Ждём 8.2.1. Спасибо за совет. Запросы элементарные. Кстати, посмотрел release notes 8.2, там есть упоминание о каком-то поправленом баге с левыми деадлоками. Возможно на него и нарвались.
8.2 пока работает, но есть непонятки. AUTOVACUUM включен, но не помогает - производительность падает. Спасает только принудительный VACUUM. Ребята разбираются.

LeXa NalBat pavelvpА PostgreSQL не может этого сделать? Религия запрещает?Не может. В постгресе нет datafiles в оракловом понимании. И нет raw devices. Ну это уж его личнные проблемы. О том и спич.
В ЛИНТЕР тоже нет "datafiles в оракловом понимании", однако планировать размеры таблиц и разносить БД по разным устройствам он умеет с рождения.

Александр ГoлдунМожет все-таки ASE, а не ASA? У SQL Anywhere (ASA) крайняя версия 10, у ASE - 15 Да, опечатка.