Re: slru.c race condition (was Re: TRAP: FailedAssertion("!((itemid)->lp_flags
В списке pgsql-hackers по дате отправления:
| От | Tom Lane |
|---|---|
| Тема | Re: slru.c race condition (was Re: TRAP: FailedAssertion("!((itemid)->lp_flags |
| Дата | |
| Msg-id | 4489.1131058947@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: slru.c race condition (was Re: TRAP: FailedAssertion("!((itemid)->lp_flags ("Jim C. Nasby" <jnasby@pervasive.com>) |
| Список | pgsql-hackers |
"Jim C. Nasby" <jnasby@pervasive.com> writes: > Seriously, I am wondering about the performance hit of always checking > debug_assertions. > http://archives.postgresql.org/pgsql-hackers/2005-08/msg00389.php > indicates that even with debug_assertions=false, --enable-cassert has a > big performance impact. That's because MEMORY_CONTEXT_CHECKING happens anyway --- it's not currently switched off by the GUC variable. I don't think we have any recent data point about the cost of Asserts per se, except your own report that it seems minimal. My thought is that it would be even more minimal if the tests of debug_assertion were removed ;-) ... except in association with Asserts that are actually testing an expensive-to-check condition, of which there are very few. regards, tom lane
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера