Re: BUG #18014: Releasing catcache entries makes schema_to_xmlschema() fail when parallel workers are used - Mailing list pgsql-bugs

From Kyotaro Horiguchi
Subject Re: BUG #18014: Releasing catcache entries makes schema_to_xmlschema() fail when parallel workers are used
Date
Msg-id 20230726.115956.975095827004068812.horikyota.ntt@gmail.com
Whole thread Raw
In response to Re: BUG #18014: Releasing catcache entries makes schema_to_xmlschema() fail when parallel workers are used  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: BUG #18014: Releasing catcache entries makes schema_to_xmlschema() fail when parallel workers are used
List 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 by date:

Previous
From: Kyotaro Horiguchi
Date:
Subject: Re: BUG #18014: Releasing catcache entries makes schema_to_xmlschema() fail when parallel workers are used
Next
From: Richard Guo
Date:
Subject: Re: BUG #17540: Prepared statement: PG switches to a generic query plan which is consistently much slower