Добрый день!

Последние полгода активно изучаю/исследую PostgreSQL и пытаюсь применить его в одном из серьезных продуктов.
Первое впечатление было очень хорошим: стройность архитектуры, богатство возможностей, удовлетворительная производительность.
Однако, приступив к более тщательному тестированию реальной БД (достаточно большой), с прискорбием обнаружил много неприятных неожиданностей.
Первое, что бросилось в глаза - весьма и весьма далекий от совершенства планировщик запросов.
Сравниваю с тем, что выдает SQLServer2005 и то, что вижу, совсем не радует.
(Предупреждая возможные замечания, отмечу, что прочитал достаточно всяких наставлений по настройке и оптимизации PG. Кое-что помогло).

Те доработки, которые были сделаны PG Development Team за это время, хотя и улучшили ситуацию, но общее ощущение ненадежности, непредсказуемости все равно никуда не делось.

На прошлой неделе поставил последний релиз 8.2.1.
В postgresql.conf изменил только один параметр: constraint_exclusion = on (нужно для партиционирования).
Позавчера сервер в первый раз "неожиданно" упал во время запроса COPY... FROM.
Смотрю в лог: 2007-01-12 17:23:16 PANIC: could not open control file "global/pg_control": Permission denied
С тех пор возникают случаи, когда при попытке выполнить какой-нибудь SELECT, можно время от времени получить ошибку сервера a-la:
ERROR: ...................: Permission denied.
Причины столь странного поведения совсем непонятны.
Есть подозрение, что дело в fsync (раньше я его всегда отключал).

Хотелось бы услышать мнение более опытных коллег об их видении PostgreSQL в свете всего выше сказанного.
А именно, насколько надежной системой представлется PG?

Данный пост, ни в коем случае не провокационный ;)

Так в общем и целом все вроде работает.
А вот иногда: "Ну не ДАЕТ!!!" ;-)

Только что обнаружил интересный пост:

pgsql-hackers-owner@postgresql.org;
Tom Lane [tgl@sss.pgh.pa.us]

[HACKERS] Idea for fixing the Windows fsync problem

I just had a thought about fixing those Windows "permission denied"
problems. The case that we believe we understand is where the bgwriter is trying to execute a previously-logged fsync request against a table file that is pending delete --- that is, actually has been unlink()'d, but some other process is holding an open file reference to it. The problem is only for fsync, not for write(), because the table drop sequence always invalidates every shared buffer for the table before trying to unlink it.

So: maybe the solution is to add a step to the drop sequence, namely revoking any pending fsync request, before unlink. This would not only clean up the Windows issue, it'd also let us remove the current hack in md.c to not complain about an ENOENT failure (which is really hardly any safer than ignoring EACCES would be, if you want to be honest about it).

The problem is that the ForwardFsyncRequest() mechanism is asynchronous:
currently, a backend could see pending fsync requests that are still in the shared-memory queue, but there's no way to tell whether the bgwriter has already absorbed some requests into its private memory. How can a backend tell the bgwriter to forget about it, and then delay until it can be sure that the bgwriter won't try it later?

We could have backends put "revoke fsync" requests into the shared queue and then sleep until they see the queue has been drained ... but there's not a convenient way to implement that delay, and I hardly want to just "sleep and retry" during every table drop. It'd probably take at least one more LWLock, and noticeably more complicated ForwardFsyncRequest() logic, to make this work.

Thoughts? Is this a reasonable solution path, or is it likely to be a waste of time? We know that there are causes of "permission denied"
that are not explained by the pending-delete problem.

Andrey Daeron
Ну, это разные СУБД, так что и планы выполнения запросов могут быть разные. Я давеча с Ораклом сравнивал, в некоторых местах далеко не в пользу последнего, а в некоторых не в пользу Постгреса - могло бы и лучше раздуплиться.
Если есть конкретные предъявы - можно обсуждать, если нет - то наверно и обсуждать нечего.

Да, предъявы имеются. Можно и обсудить.
Хотя, наверное, это надо напрямую девелоперам жалиться.
В сравнении с SQLServer2005, PG стабильно проигрывает приблизительно в 2 раза.
С Ораклом не сранивал.
Зато сравнивал SQLServer2005 c SQLServer2000 и надо честно признаться, чувствуется, что интеллектуальность планировщика на порядок стала лучше. Но это к слову...

Andrey DaeronА какая ОС?
WinXP Pro SP2 (English)

Andrey DaeronУ меня ПГ упал на памяти три раза.
1-й БедБДлок на винте, умерла таблица,
2-й умудрились поставить его на FAT32 и что-то случилось с БД,
3-й каким-то загадочным неизвестным науке способом доочищались места на винте до того, что удалили часть фалов PG.
Есть информация о серьезным применении еще 7.4 версии в учетных системах.

Продолжаю читать pg-рассылку.
Все больше прихожу к выводу, что какой-то косяк ребята привнесли в один из последних релизов.
Ну не может быть чтобы "друг, оказался вдруг...".

SQLServer2005 у вас работал как блочник или версионник?
Как блочник.
Однако, и в версионном режиме аналогичные результаты.