On 2/20/20 11:28 AM, Albrecht Dreß wrote:
> Am 20.02.20 19:32 schrieb(en) Tom Lane:
>> This is, actually, not very surprising. You dropped the old function
>> while clients were using it. The new function is a completely
>> unrelated object, even if it happens to have the same name.
>
> Yes, I agree that this was not a too clever approach…
>
>> It does seem a bit annoying that something in plpgsql is apparently
>> doing a fresh catalog lookup to find information that likely was
>> already cached at the start of function execution.
>
> OK, but after fully stopping the daemon via systemctl (which of course
> disconnects all clients) and re-starting it, the cache is empty, isn't
> it? So the client after re-connecting /should/ find the proper
> function? In my case the full restart did *not* help, but produced the
> same error again afterwards! I didn't reboot the whole box, though.
It would be nice to know what:
[…]
represented in:
CREATE FUNCTION public.get_result2(mytaskid bigint, OUT data bytea, OUT
metadata jsonb, OUT errortext text, OUT vanished boolean) RETURNS record
[…]
COMMIT;
The Postgres logs during and after restart might provide some info.
Also the errors thrown when accessing the other function.
>
> This led me to the assumption that the database was “somehow” damaged.
>
> Thanks,
> Albrecht.
--
Adrian Klaver
adrian.klaver@aklaver.com
