> On Sun, Jan 22, 2023 at 07:47:07PM +0100, Pavel Stehule wrote:
> pá 20. 1. 2023 v 21:35 odesílatel Dmitry Dolgov <9erthalion6@gmail.com>
> napsal:
>
> > * I think it was already mentioned in the thread, there seems to be not a
> > single usage of CHECK_FOR_INTERRUPTS in session_variable.c . But some
> > number
> > of loops over the sessionvars are implemented, are they always going to
> > be
> > small enough to not make any troubles?
> >
>
> The longest cycle is a cycle that rechecks actively used variables against
> system catalog. No cycle depends on the content of variables.
Right, but what about the cases with huge number of variables? Not
saying it could be in any sense common, but possible to do.
Now I tested 10K variables (with enabled assertions, without it is should be faster)
creating 763ms
do $$ begin for i in 1..10000 loop execute format('create variable %I as int', 'xx' || i); end loop; end $$;
assigning 491ms
do $$ begin for i in 1..10000 loop execute format('let %I = 10', 'xx' || i); end loop; end $$;
dropping without necessity of memory cleaning 1155ms
do $$ begin for i in 1..10000 loop execute format('drop variable %I', 'xx' || i); end loop; end $$;
dropping with memory cleaning 2708
just memory cleaning 72ms (time of commit - at commit cleaning)
do $$ begin for i in 1..10000 loop execute format('let %I = 10', 'xx' || i); end loop; end $$;
begin;
do $$ begin for i in 1..10000 loop execute format('drop variable %I', 'xx' || i); end loop; end $$;
commit;
So just syncing (cleaning 10K) variables needs less than 72 ms
I can be wrong, but from these numbers I don't think so these sync cycles should to contain CHECK_FOR_INTERRUPTS
What do you think?
> > * sync_sessionvars_all explains why is it necessary to copy
> > xact_recheck_varids:
> >
> > When we check the variables, the system cache can be
> > invalidated,
> > and xact_recheck_varids can be enhanced.
> >
> > I'm not quite following what the "enhancement" part is about? Is
> > xact_recheck_varids could be somehow updated concurrently with the loop?
> >
>
> Yes. pg_variable_cache_callback can be called when
> is_session_variable_valid is executed.
>
> Maybe "extended" can be a better word instead of "enhanced"? I reformulated
> this comment
Yeah, "extended" sounds better. But I was mostly confused about the
mechanism, if the cache callback can interrupt the execution at any
moment when called, that would explain it.
patch from yesterday has extended comment in this area :-)
Regards
Pavel