Re: GiST concurrency commited

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: GiST concurrency commited
Дата
Msg-id 6946.1119883087@sss.pgh.pa.us
обсуждение исходный текст
Ответ на GiST concurrency commited  (Teodor Sigaev <teodor@sigaev.ru>)
Ответы Re: GiST concurrency commited  (Christopher Kings-Lynne <chriskl@familyhealth.com.au>)
Re: GiST concurrency commited  (Teodor Sigaev <teodor@sigaev.ru>)
Список pgsql-hackers
Teodor Sigaev <teodor@sigaev.ru> writes:
> While I'm running test with concurrent
> select/insert/update/delete/vacuum/vacuum full I found, that sometimes
> postgres crashes in index_beginscan_internal on FunctionCall3, because
> structure 'procedure' becomes zeroed. As I understand, LockRelation
> can invalidate part of Relation structure. So, I moved
> GET_REL_PROCEDURE after LockRelation.

Oooh, good catch.

> It seems to me, this patch
> should be backpatched or it's needed another fixing.

No, it's not an issue in the back branches, because until recently
GET_REL_PROCEDURE only fetched the function OID.

> And there is one more problem: it caused approximatly one time per 2-4 million 
> statements, I got traps:
> TRAP: FailedAssertion("!((*curpage)->offsets_used == num_tuples)", File: 
> "vacuum.c", Line: 2766)
> LOG:  server process (PID 15847) was terminated by signal 6

Odd.  Will look at it later (after feature freeze), if you don't find
the cause beforehand.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: strk
Дата:
Сообщение: Re: accessing postgres conf from stored procedure
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Questions on extending a relation