Re: Cache invalidation after authentication (on-the-fly role creation) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Cache invalidation after authentication (on-the-fly role creation)
Date
Msg-id 67543.1530740105@sss.pgh.pa.us
Whole thread Raw
In response to Cache invalidation after authentication (on-the-fly role creation)  (Thomas Munro <thomas.munro@enterprisedb.com>)
Responses Re: Cache invalidation after authentication (on-the-fly role creation)  (Thomas Munro <thomas.munro@enterprisedb.com>)
List pgsql-hackers
Thomas Munro <thomas.munro@enterprisedb.com> writes:
> I'd like to do this to postinit.c:

>                 PerformAuthentication(MyProcPort);
> +               AcceptInvalidationMessages();
>                 InitializeSessionUserId(username, useroid);

> Any objections?

That seems like a *really* ad-hoc place to put it.  Why should it be
there, and not (say) somewhere inside InitializeSessionUserId, or maybe
(also?) inside PerformAuthentication?  Why do the existing call sites for
AcceptInvalidationMessages --- in particular, the ones associated with
lock acquisition --- not solve the problem already?

I'm not opposed to trying to make things better if we have a stale-cache
problem during init, just dubious that this is how to do it.

            regards, tom lane


pgsql-hackers by date:

Previous
From: "David G. Johnston"
Date:
Subject: Re: Unexpected behavior of DROP VIEW/TABLE IF EXISTS
Next
From: Thomas Munro
Date:
Subject: setproctitle_fast()