Re: BUG #18014: Releasing catcache entries makes schema_to_xmlschema() fail when parallel workers are used
От | Kyotaro Horiguchi |
---|---|
Тема | Re: BUG #18014: Releasing catcache entries makes schema_to_xmlschema() fail when parallel workers are used |
Дата | |
Msg-id | 20230720.162802.905550494964943231.horikyota.ntt@gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #18014: Releasing catcache entries makes schema_to_xmlschema() fail when parallel workers are used (Alexander Lakhin <exclusion@gmail.com>) |
Ответы |
Re: BUG #18014: Releasing catcache entries makes schema_to_xmlschema() fail when parallel workers are used
|
Список | pgsql-bugs |
At Sun, 16 Jul 2023 23:00:01 +0300, Alexander Lakhin <exclusion@gmail.com> wrote in > The parallel worker doesn't have a lock on pg_class_oid_index before > executing the query, so it gets the lock and res == LOCKACQUIRE_OK > (not > LOCKACQUIRE_ALREADY_CLEAR as in a regular backend case), after that it > processes invalidation messages (this can make the backend use a newer > catalog snapshot), and at the end it does systable_endscan() -> > index_close() -> UnlockRelationId() -> LockRelease()... > Thus, on a next iteration it gets the lock anew, with the res == > LOCKACQUIRE_OK > again, and all that ceremony repeated. > > It's not clear to me, whether this parallel worker behavior is > expected and > if so, what to fix to avoid the test failure. That is, the function is not parallel-safe. In fact it is marked as 'r' in pg_proc.proparallel. So, the real question appears to be how it ended up running in a paralell worker. regards. -- Kyotaro Horiguchi NTT Open Source Software Center
В списке pgsql-bugs по дате отправления: