On 3/22/22 18:18, Tom Lane wrote: > Andrew Dunstan <and...@dunslane.net> writes: >> Fixed > Now that we got past the hard failures, we can see that the test > falls over with (some?) non-default encodings, as for instance > here: > > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=prion&dt=2022-03-22%2020%3A23%3A13 > > I can replicate that by running the test under LANG=en_US.iso885915. > What I think is happening is: > > (1) Rather unwisely, the relevant InvokeNamespaceSearchHook calls > appear in recomputeNamespacePath. That means that their timing > depends heavily on accidents of caching. > > (2) If we decide that we need an encoding conversion to talk to > the client, there'll be a lookup for the conversion function > early during session startup. That will cause the namespace > search path to get computed then, before the test module has been > loaded and certainly before the audit GUC has been turned on. > > (3) At the point where the test expects some audit notices > to come out, nothing happens because the search path is > already validated. > > I'm inclined to think that (1) is a seriously bad idea, > not only because of this instability, but because > > (a) the namespace cache logic is unlikely to cause the search-path > cache to get invalidated when something happens that might cause an > OAT hook to wish to change its decision, and > > (b) this placement means that the hook is invoked during cache loading > operations that are likely to be super-sensitive to any additional > catalog accesses a hook might wish to do. (I await the results of the > CLOBBER_CACHE_ALWAYS animals with trepidation.) > > Now, if our attitude to the OAT hooks is that we are going to > sprinkle some at random and whether they are useful is someone > else's problem, then maybe these are not interesting concerns.
So this was a pre-existing problem that the test has exposed? I don't think we can just say "you deal with it", and if I understand you right you don't think that either. I could make the buildfarm quiet again by resetting NO_INSTALLCHECK temporarily. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
