drill-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Abhishek Girish <abhishek.gir...@gmail.com>
Subject Re: Resetting an option
Date Thu, 17 Sep 2015 22:03:56 GMT
I think that would remain similar to current behavior. Changing both system
and session options today, changes defaults for both. But session level
option takes precedence for that session.

select name,type,status,num_val from sys.options where name like
'%max_query_memory_per_node%';
*+-------------------------------------------+----------+----------+--------------+*
*| **                  name                   ** | **  type  ** | **
status ** | **  num_val   ** |*
*+-------------------------------------------+----------+----------+--------------+*
*| *planner.memory.max_query_memory_per_node * | *SYSTEM  * | *CHANGED * | *
21474836485 * |*
*| *planner.memory.max_query_memory_per_node * | *SESSION * | *CHANGED * | *
21474836480 * |*
*+-------------------------------------------+----------+----------+--------------+*

2 rows selected (0.313 seconds)

So in the scenario you mentioned, I think "ALTER SYSTEM RESET A", should
reset A only at the SYSTEM level but leave it changed at the SESSION level.

-Abhishek


On Thu, Sep 17, 2015 at 2:42 PM, Abdel Hakim Deneche <adeneche@maprtech.com>
wrote:

> I am looking at the corresponding pull request:
>
> https://github.com/apache/drill/pull/159
>
> and I have a question I can't seem to find an answer in this discussion:
>
> Let's say a user changes an option A both at the SESSION and SYSTEM level.
> What happens when the users issues "ALTER SYSTEM RESET A", does it reset A
> only at the SYSTEM level but leave it changed at the SESSION level, or do
> we want it to reset both SESSION and SYSTEM levels of A ?
>
>
>
> On Mon, Aug 10, 2015 at 3:24 PM, Abhishek Girish <agirish@mapr.com> wrote:
>
> > A session level *set* operation, by definition, should override the
> > corresponding system level option for the duration of the session.
> >
> > Going by that, I think, a *reset* operation should default it back to the
> > value held by the system level option. If a user (say an admin) has
> updated
> > the corresponding system option, the reverted value would be a custom,
> > non-Drill-default value. And if not, the reverted value would be the
> > Drill-default value. This would make it simpler to manage.
> >
> >
> > On Mon, Aug 10, 2015 at 2:51 PM, Jason Altekruse <
> altekrusejason@gmail.com
> > >
> > wrote:
> >
> > > I don't know if I missed something, but the Postgres docs seem to
> > indicate
> > > that there is no equivalent to the concept of a SYSTEM option that
> exists
> > > in Drill, which can be set with a query. Options can be set at server
> > > startup, either in a configuration file or with a command line
> parameter
> > > [2]. Once the server is running, it appears that the closest to our
> ALTER
> > > SYSTEM statement would be the feature to set options at a user or
> > database
> > > level [2].
> > >
> > > Here is an excerpt from the docs on the DEFAULT option value: [1] -
> > DEFAULT
> > > can be written to specify resetting the parameter to its default value
> > > (that is, whatever value it would have had if no SET had been executed
> in
> > > the current session).
> > >
> > > We should probably just try it out to confirm, but this statement leads
> > me
> > > to believe that the option will return to the value set in the startup
> > > config file/parameter or what was set at the user/database level, not
> the
> > > system default. This is in agreement with my intuition on the issue,
> the
> > > whole idea behind nesting these configurations, from Drill default to
> > > System and then to Session would seem to be trying to provide users
> with
> > > the safest environment possible.
> > >
> > > Setting something at the system level should only be done if the
> > > administrator is certain that the non-standard option is a helpful
> > > modification for the majority of their users. Thus users can choose to
> > > override it, but their escape hatch should bring them back to the
> option
> > > values given by their administrator, not Drill defaults.
> > >
> > > [1] http://www.postgresql.org/docs/9.2/static/sql-set.html
> > > [2] http://www.postgresql.org/docs/9.2/static/config-setting.html
> > >
> > > On Mon, Aug 10, 2015 at 2:25 PM, Sudheesh Katkam <skatkam@maprtech.com
> >
> > > wrote:
> > >
> > > > Correction: currently any user can SET or RESET an option for session
> > and
> > > > system.
> > > >
> > > > > On Aug 10, 2015, at 2:20 PM, Sudheesh Katkam <skatkam@maprtech.com
> >
> > > > wrote:
> > > > >
> > > > > Hey y‘all,
> > > > >
> > > > > Re DRILL-1065 <https://issues.apache.org/jira/browse/DRILL-1065>,
> at
> > > > system level (ALTER system RESET …), resetting an option would mean
> > > > changing the value to the default provided by Drill. But, at session
> > > level
> > > > (ALTER session RESET …), would resetting an option mean:
> > > > > (a) changing the value to the default provided by Drill? or,
> > > > > (b) changing the value to the system value, that an admin could’ve
> > > > changed?
> > > > >
> > > > > (b) would not allow non-admin users to know what the default is
> > > > (easily). However, for a given option, (a) would allow a non-admin
> user
> > > to
> > > > know what the default is (by resetting) and what the system setting
> is
> > > > (from sys.options). Opinions?
> > > > >
> > > > > Thank you,
> > > > > Sudheesh
> > > >
> > > >
> > >
> >
>
>
>
> --
>
> Abdelhakim Deneche
>
> Software Engineer
>
>   <http://www.mapr.com/>
>
>
> Now Available - Free Hadoop On-Demand Training
> <
> http://www.mapr.com/training?utm_source=Email&utm_medium=Signature&utm_campaign=Free%20available
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message