Re: Segmentation fault when calling BlessTupleDesc in a C function in parallel on PostgreSQL-(12.6, 12.7, 13.2, 13.3)
От | Thomas Munro |
---|---|
Тема | Re: Segmentation fault when calling BlessTupleDesc in a C function in parallel on PostgreSQL-(12.6, 12.7, 13.2, 13.3) |
Дата | |
Msg-id | CA+hUKGK8ib9c5h-+uQudQ0+CGAx23h6XAAns9pL+pVgHfV2REQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Segmentation fault when calling BlessTupleDesc in a C function in parallel on PostgreSQL-(12.6, 12.7, 13.2, 13.3) (Eric Thinnes <e.thinnes@gmx.de>) |
Ответы |
Re: Segmentation fault when calling BlessTupleDesc in a C function in parallel on PostgreSQL-(12.6, 12.7, 13.2, 13.3)
|
Список | pgsql-bugs |
On Sat, May 15, 2021 at 5:42 AM Eric Thinnes <e.thinnes@gmx.de> wrote: > Because of the parallelism it is difficult to debug the error. > I have less experience with that. I was able to reproduce the problem using your test.c/test.sql. It's a bug in PostgreSQL. BlessTupleDesc() is supposed to work correctly in any process in a parallel query since the typmods are shared (since PG 11, before that there was a different arrangement involving translation), but there is a low probability edge case that your test manages to hit fairly reliably, where two backends try to bless a tuple with matching attributes at exactly the same time, and then the one that loses the race switches to using the TupleDesc blessed by the other, but it dereferences the wrong pointer (or rather, a non-pointer with a similar name...) here: /* Return the one we found. */ Assert(record_table_entry->key.shared); result = (TupleDesc) dsa_get_address(CurrentSession->area, - record_table_entry->key.shared); + record_table_entry->key.u.shared_tupdesc); Assert(result->tdrefcount == -1); With that change I can see it still hits this path often but works correctly. Will fix next week.
В списке pgsql-bugs по дате отправления: