Re: [BUGS] 7.4 beta 1: SET log_statement=false
От | Bertrand Petit |
---|---|
Тема | Re: [BUGS] 7.4 beta 1: SET log_statement=false |
Дата | |
Msg-id | 20030814010529.A1801@memo.frmug.org обсуждение исходный текст |
Ответ на | Re: [BUGS] 7.4 beta 1: SET log_statement=false (Bruce Momjian <pgman@candle.pha.pa.us>) |
Список | pgsql-hackers |
On Wed, Aug 13, 2003 at 06:05:46PM -0400, Bruce Momjian wrote: > I tried adding this line: > > record->session_source < PGC_S_UNPRIVILEGED && > > and it does allow you to set the variable to false if you have set it to > true in your session, but it also allows you to set it to false if it is > set to true in postgresql.conf. You do this by setting it to 'true' > _then_ to 'false' in your session. The reason this works is that there > is no history in the GUC code to record the value this variable was set > at various locations. Once you set it to 'true' in your session, the > system remembers that, and forgets it was also set to true in > postgresql.conf, and therefore allows you to set it to false. The following describes what I would do if I had the controls on the postgres source code: I would put the lambda-user protected configuration parameters under the control of a system similar to what is used for the {get|set}rlimit system calls. At the begining of a session, a snapshot of the parameters is taken, it is kept appart from the live parameters. The snapshot would be used by the parameters controller to permit or deny a parameter change depending on the snaphot value, the current value, the desired new value and a set of rules. A rule could express things like theses: * boolean values: * deny change if the new value would transition from true to false and the snapshot value is true; * allow change if the new value would transition from true to false and the snapshot value is false; * and any the the negation and/or inverse of both of these rules. * numerical values: * deny the change if the new value would be less than the snapshot value and the current value is larger than thesnapshot value; * deny the change if the new value would be greater than the snapshot value and the current value is less than thesnapshot value; * new textual values would be matched against a set of acceptable or unacceptable user values, the status returned bythe countroller would be according the matched set. A scheme like this would allow a tolerance from the user point of view while fixing limits on what can be done by non-superuser accounts. It could also be interesting to tie the parameters set to transactions: parameters changed while inside a transaction could be reset to their default or pre-transactions values on a commit or rollback. This could look like the behavior of the save/restore postscript operators. Regards. -- %!PS 297.6 420.9 translate 90 rotate 0 setgray gsave 0 1 1{pop 0 180 moveto 100 180 170 100 170 -10 curveto 180 -9 180 -9 190 -10 curveto 190 100 100 180 0 180 curveto fill 180 rotate}for grestore/Bookman-LightItalic findfont 240 scalefont setfont -151.536392 -63.7998886 moveto (bp)show showpage
В списке pgsql-hackers по дате отправления: