Re: Schema variables - new implementation for Postgres 15 (typo) - Mailing list pgsql-hackers

From Dmitry Dolgov
Subject Re: Schema variables - new implementation for Postgres 15 (typo)
Date
Msg-id 20230124095644.cuwy5wrqccxukv2u@ddolgov.remote.csb
Whole thread Raw
In response to Re: Schema variables - new implementation for Postgres 15 (typo)  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: Schema variables - new implementation for Postgres 15 (typo)
List pgsql-hackers
> On Mon, Jan 23, 2023 at 07:09:27PM +0100, Pavel Stehule wrote:
> po 23. 1. 2023 v 15:25 odesílatel Dmitry Dolgov <9erthalion6@gmail.com>
> napsal:
>
> > > 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)
>
> [...]
>
> 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?

Well, there is always possibility someone will create more variables
than any arbitrary limit we have tested for. But I see your point and
don't have a strong opinion about this, so let's keep it as it is :)

> > > > * 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 :-)

Thanks!



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Time delayed LR (WAS Re: logical replication restrictions)
Next
From: Hans Buschmann
Date:
Subject: Re: Making Vars outer-join aware