Re: BUG #18014: Releasing catcache entries makes schema_to_xmlschema() fail when parallel workers are used
От | Tom Lane |
---|---|
Тема | Re: BUG #18014: Releasing catcache entries makes schema_to_xmlschema() fail when parallel workers are used |
Дата | |
Msg-id | 982076.1689967306@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | 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 |
Alexander Lakhin <exclusion@gmail.com> writes: > 21.07.2023 20:20, Tom Lane wrote: >> I like #2 better if it's not hard to do cleanly. However, I'm not >> quite sure how we are getting to an inval during relation close; >> maybe that's not something we want to prevent. > Yes, there is a detailed comment in LockRelationOid(), that explains why > AcceptInvalidationMessages() is called. (I've tried to remove that call > now, just for testing, and get 6 tests failed during `make check`.) Yes, we certainly want to do that during LockRelationOid. But what seems to be happening here is an inval while we are closing/unlocking the catalog we got the syscache entry from. That is, the expected behavior here is: SearchSysCacheExists: * is entry present-and-valid? No, so... * open and lock relevant catalog (with possible inval) * scan catalog, find desired row, create valid syscache entry * close and unlock catalog * return success SearchSysCache1 (from pg_class_aclmask_ext): * is entry present-and-valid? Yes, so increment its refcount and return it There is no inval in the entry-already-present code path in syscache lookup. So if we are seeing this failure, ISTM it must mean that an inval is happening during "close and unlock catalog", which seems like something that we don't want. But I've not traced exactly how that happens. regards, tom lane
В списке pgsql-bugs по дате отправления: