Craig Ringer <craig@2ndquadrant.com> writes:
> On 03/06/2014 02:58 AM, Tom Lane wrote:
>> The PlanInvalItem could perfectly well be generated by the planner,
>> no, if it has the user OID? But I'm not real sure why you need it.
>> I don't see the reason for an invalidation triggered by user ID.
>> What exactly about the *user*, and not something else, would trigger
>> plan invalidation?
> It's only that the plan depends on the user ID. There's no point keeping
> the plan around if the user no longer exists.
[ shrug... ] Leaving such a plan cached would be harmless, though.
Furthermore, the user ID we'd be talking about is either the owner
of the current session, or the owner of some view or security-definer
function that the plan is already dependent on, so it's fairly hard
to credit that the plan would survive long enough for the issue to
arise.
Even if there is a scenario where invalidating by user ID is actually
useful, I think adding infrastructure to cause invalidation in such a case
is optimizing for the wrong thing. You're adding cycles to every query to
benefit a case that is going to be quite infrequent in practice.
>> What we do need is a notion that a plan cache entry might only be
>> valid for a specific calling user ID; but that's a matter for cache
>> entry lookup not for subsequent invalidation.
> Yes, that would be good, but is IMO more of a separate optimization. I'm
> currently using KaiGai's code to invalidate and re-plan when a user ID
> change is detected.
I'm unlikely to accept a patch that does that; wouldn't it be catastrophic
for performance in the presence of security-definer functions? You can't
just trash the whole plan cache when a user ID switch occurs.
regards, tom lane