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 | 20230726.115956.975095827004068812.horikyota.ntt@gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #18014: Releasing catcache entries makes schema_to_xmlschema() fail when parallel workers are used (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #18014: Releasing catcache entries makes schema_to_xmlschema() fail when parallel workers are used
|
Список | pgsql-bugs |
At Tue, 25 Jul 2023 22:41:57 -0400, Tom Lane <tgl@sss.pgh.pa.us> wrote in > Kyotaro Horiguchi <horikyota.ntt@gmail.com> writes: > > Doesn't this imply that the function isn't parallel-safe? The issue is > > gone by marking it and all variants as parallel-restricted. > > As I said earlier, I think that's a purely coincidental "fix" for > this specific manifestation. Either SearchSysCacheExists followed > by a syscache lookup of the same tuple should be considered safe, > or it shouldn't. If it should be considered safe, we need to fix the (So, it came to this after all..) Yeah, as I posted at the same time, what I meant is not that the sequence is unsafe. It is safe even on a parallel worker. What I meant was that there seems to be a case where it returns different result for the same parameters if they are called on different workers. > cache-clobber test scaffolding to not give a false positive. While if > it shouldn't, we need to get rid of that coding pattern, not apply > high-level band-aids that remove just one particular path to reaching > the problem. I'm not dead set on either answer at this point, but > I think those are the plausible alternatives. Right. regards. -- Kyotaro Horiguchi NTT Open Source Software Center
В списке pgsql-bugs по дате отправления: