From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>, Julien Rouhaud <rjuju123(at)gmail(dot)com>, Joshua Brindle <joshua(dot)brindle(at)crunchydata(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>, Joe Conway <joe(at)crunchydata(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net> |
Subject: | Re: New Object Access Type hooks |
Date: | 2022-03-22 23:51:20 |
Message-ID: | 6067945b-960a-ab04-d40f-06b006a1dcd0@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 3/22/22 18:18, Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Zhihong Yu | 2022-03-22 23:54:08 | Re: Window Function "Run Conditions" |
Previous Message | Tom Lane | 2022-03-22 23:48:55 | Re: SQL/JSON: functions |