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. regards, tom lane
