Sawada,
* Sawada Masahiko (sawada.m...@gmail.com) wrote:
Thank you for reviewing.
I agree with this.
Attached patch is updated version v10.
Committed with quite a few additional changes and improvements. Please
take a look, test, and let me know if you see any issues or have any
concerns.
On Wed, Apr 29, 2015 at 12:20 AM, David Steele da...@pgmasters.net wrote:
On 4/27/15 10:37 PM, Sawada Masahiko wrote:
Thank you for your reviewing.
Attached v8 patch is latest version.
I posted a review through the CF app but it only went to the list
instead of recipients of the latest
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, passed
Looks good - ready for committer.
The new status of this
On Fri, Apr 24, 2015 at 2:40 PM, David Steele da...@pgmasters.net wrote:
para
The view structnamepg_file_settings/structname provides access to
run-time parameters
that are defined in configuration files via SQL. In contrast to
structnamepg_settings/structname a row is provided
On 4/29/15 5:16 PM, Robert Haas wrote:
On Fri, Apr 24, 2015 at 2:40 PM, David Steele da...@pgmasters.net wrote:
para
The view structnamepg_file_settings/structname provides access to
run-time parameters
that are defined in configuration files via SQL. In contrast to
On Thu, Apr 30, 2015 at 6:31 AM, David Steele da...@pgmasters.net wrote:
On 4/29/15 5:16 PM, Robert Haas wrote:
On Fri, Apr 24, 2015 at 2:40 PM, David Steele da...@pgmasters.net wrote:
para
The view structnamepg_file_settings/structname provides access to
run-time parameters
that are
On 4/27/15 10:37 PM, Sawada Masahiko wrote:
Thank you for your reviewing.
Attached v8 patch is latest version.
I posted a review through the CF app but it only went to the list
instead of recipients of the latest message. install-checkworld is
failing but the fix is pretty trivial.
See:
The following review has been posted through the commitfest application:
make installcheck-world: tested, failed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, passed
Looks good overall, but make installcheck-world does not
On Sat, Apr 25, 2015 at 3:40 AM, David Steele da...@pgmasters.net wrote:
On 4/4/15 9:21 AM, Sawada Masahiko wrote:
I added documentation changes to patch is attached.
Also I tried to use memory context for allocation of guc_file_variable
in TopMemoryContext,
but it was failed access after
On Tue, Apr 28, 2015 at 3:22 AM, David Steele da...@pgmasters.net wrote:
On 4/27/15 10:31 AM, Sawada Masahiko wrote:
Thank you for your review comment!
The latest patch is attached.
Looks good overall - a few more comments below:
Thank you for your reviewing.
Attached v8 patch is latest
On Mon, Apr 27, 2015 at 11:31 PM, Sawada Masahiko sawada.m...@gmail.com wrote:
On Sat, Apr 25, 2015 at 3:40 AM, David Steele da...@pgmasters.net wrote:
On 4/4/15 9:21 AM, Sawada Masahiko wrote:
I added documentation changes to patch is attached.
Also I tried to use memory context for
On 4/27/15 10:31 AM, Sawada Masahiko wrote:
Thank you for your review comment!
The latest patch is attached.
Looks good overall - a few more comments below:
diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml
+row
+ entrystructfieldseqno/structfield/entry
+
On Wed, Mar 11, 2015 at 11:46 PM, Sawada Masahiko sawada.m...@gmail.com wrote:
On Tue, Mar 10, 2015 at 12:08 PM, Stephen Frost sfr...@snowman.net wrote:
Sawada,
* Sawada Masahiko (sawada.m...@gmail.com) wrote:
Thank you for your review!
Attached file is the latest version (without document
On Tue, Mar 10, 2015 at 12:08 PM, Stephen Frost sfr...@snowman.net wrote:
Sawada,
* Sawada Masahiko (sawada.m...@gmail.com) wrote:
Thank you for your review!
Attached file is the latest version (without document patch. I making it
now.)
As per discussion, there is no change regarding of
* Stephen Frost (sfr...@snowman.net) wrote:
--- a/src/backend/catalog/system_views.sql
+++ b/src/backend/catalog/system_views.sql
@@ -414,6 +414,11 @@ CREATE RULE pg_settings_n AS
GRANT SELECT, UPDATE ON pg_settings TO PUBLIC;
+CREATE VIEW pg_file_settings AS
+ SELECT * FROM
Sawada,
* Sawada Masahiko (sawada.m...@gmail.com) wrote:
Thank you for your review!
Attached file is the latest version (without document patch. I making it now.)
As per discussion, there is no change regarding of super user permission.
Ok. Here's another review.
diff --git
On Sat, Feb 28, 2015 at 2:27 PM, Stephen Frost sfr...@snowman.net wrote:
Sawada,
* Sawada Masahiko (sawada.m...@gmail.com) wrote:
Attached patch is latest version including following changes.
- This view is available to super use only
- Add sourceline coulmn
Alright, first off, to Josh's
* Peter Eisentraut (pete...@gmx.net) wrote:
On 3/3/15 5:29 PM, Stephen Frost wrote:
For my part, I understood that we specifically didn't want to allow that
for the same reason that we didn't want to simply depend on the GRANT
system for the above functions, but everyone else on these
* Peter Eisentraut (pete...@gmx.net) wrote:
On 3/3/15 5:58 PM, Tom Lane wrote:
One aspect of this that merits some thought is that in some cases
access to some set of functions is best granted as a unit. That's
easy with role properties but much less so with plain GRANT.
Do we have
On 3/3/15 5:58 PM, Tom Lane wrote:
Stephen Frost sfr...@snowman.net writes:
It's not a documented policy but it's certainly what a whole slew of
functions *do*. Including pg_start_backup, pg_stop_backup,
pg_switch_xlog, pg_rotate_logfile, pg_create_restore_point,
pg_xlog_replay_pause,
On 3/3/15 5:29 PM, Stephen Frost wrote:
For my part, I understood that we specifically didn't want to allow that
for the same reason that we didn't want to simply depend on the GRANT
system for the above functions, but everyone else on these discussions
so far is advocating for using the GRANT
On 3/2/15 4:47 PM, Robert Haas wrote:
On Sat, Feb 28, 2015 at 12:27 AM, Stephen Frost sfr...@snowman.net wrote:
While this generally works, the usual expectation is that functions
that should be superuser-only have a check in the function rather than
depending on the execute privilege. I'm
* Robert Haas (robertmh...@gmail.com) wrote:
On Sat, Feb 28, 2015 at 12:27 AM, Stephen Frost sfr...@snowman.net wrote:
While this generally works, the usual expectation is that functions
that should be superuser-only have a check in the function rather than
depending on the execute
Jim,
* Jim Nasby (jim.na...@bluetreble.com) wrote:
On 3/3/15 5:22 PM, Stephen Frost wrote:
The
problem with the role attribute approach is that they aren't inheirted
the way GRANTs are, which means you can't have a backup role that is
then granted out to users, you'd have to set a BACKUP
On Tue, Mar 3, 2015 at 10:29 PM, Stephen Frost sfr...@snowman.net wrote:
-1. If that policy exists at all, it's a BAD policy, because it
prevents users from changing the permissions using DDL. I think the
superuser check should be inside the function, when, for example, it
masks some of the
Stephen Frost sfr...@snowman.net writes:
It's not a documented policy but it's certainly what a whole slew of
functions *do*. Including pg_start_backup, pg_stop_backup,
pg_switch_xlog, pg_rotate_logfile, pg_create_restore_point,
pg_xlog_replay_pause, lo_import, lo_export, and
On 3/3/15 5:22 PM, Stephen Frost wrote:
The
problem with the role attribute approach is that they aren't inheirted
the way GRANTs are, which means you can't have a backup role that is
then granted out to users, you'd have to set a BACKUP role attribute
for every role added.
Yeah, but you'd
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Stephen Frost sfr...@snowman.net writes:
The discussion I'm having with Peter on another thread is a very similar
case that should be looping in, which is if we should continue to have
any superuser check on updating catalog tables. He is advocating
* Stephen Frost (sfr...@snowman.net) wrote:
pg_start_backup, pg_stop_backup, pg_switch_xlog, pg_rotate_logfile,
pg_create_restore_point, pg_xlog_replay_pause, lo_import, lo_export,
and pg_xlog_replay_resume.
Meh, that list was too hastily copied and pasted from my earlier email.
lo_import and
On Sat, Feb 28, 2015 at 12:27 AM, Stephen Frost sfr...@snowman.net wrote:
While this generally works, the usual expectation is that functions
that should be superuser-only have a check in the function rather than
depending on the execute privilege. I'm certainly happy to debate the
merits of
On 2/27/15 11:27 PM, Stephen Frost wrote:
@@ -344,6 +346,21 @@ ProcessConfigFile(GucContext context)
PGC_BACKEND,
PGC_S_DYNAMIC_DEFAULT);
}
+ guc_file_variables = (ConfigFileVariable *)
+ guc_malloc(FATAL,
Sawada,
* Sawada Masahiko (sawada.m...@gmail.com) wrote:
Attached patch is latest version including following changes.
- This view is available to super use only
- Add sourceline coulmn
Alright, first off, to Josh's point- I'm definitely interested in a
capability to show where the heck a
This would default to being available to superusers only, right? Details
of the file system shouldn't be available to any random user.
__
*Mike Blackwell | Technical Analyst, Distribution Services/Rollout
On Fri, Jan 30, 2015 at 09:38:10PM +0900, Sawada Masahiko wrote:
On Tue, Jan 27, 2015 at 3:34 AM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Jan 22, 2015 at 5:19 PM, Tom Lane t...@sss.pgh.pa.us wrote:
David Johnston david.g.johns...@gmail.com writes:
On Thu, Jan 22, 2015 at 3:04 PM,
On Sat, Jan 31, 2015 at 12:58 AM, Mike Blackwell mike.blackw...@rrd.com wrote:
This would default to being available to superusers only, right? Details of
the file system shouldn't be available to any random user.
This WIP patch does not behave like that, but I agree.
This view would be
On Sat, Jan 31, 2015 at 12:24 AM, David Fetter da...@fetter.org wrote:
On Fri, Jan 30, 2015 at 09:38:10PM +0900, Sawada Masahiko wrote:
On Tue, Jan 27, 2015 at 3:34 AM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Jan 22, 2015 at 5:19 PM, Tom Lane t...@sss.pgh.pa.us wrote:
David Johnston
David Johnston david.g.johns...@gmail.com writes:
On Fri, Jan 30, 2015 at 12:05 PM, David Fetter da...@fetter.org wrote:
Why might the contents of pg_settings be different from what would be
in pg_file_settings, apart from the existence of this column?
ââThe contents of pg_settings uses
On Fri, Jan 30, 2015 at 12:05 PM, David Fetter da...@fetter.org wrote:
On Sat, Jan 31, 2015 at 12:50:20AM +0900, Sawada Masahiko wrote:
[postgres][5432](1)=# select * from pg_file_settings where name =
'work_mem';
-[ RECORD 1 ]--
name
On Sat, Jan 31, 2015 at 12:50:20AM +0900, Sawada Masahiko wrote:
On Sat, Jan 31, 2015 at 12:24 AM, David Fetter da...@fetter.org wrote:
On Fri, Jan 30, 2015 at 09:38:10PM +0900, Sawada Masahiko wrote:
On Tue, Jan 27, 2015 at 3:34 AM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Jan 22,
On Sat, Jan 31, 2015 at 4:56 AM, Tom Lane t...@sss.pgh.pa.us wrote:
David Johnston david.g.johns...@gmail.com writes:
On Fri, Jan 30, 2015 at 12:05 PM, David Fetter da...@fetter.org wrote:
Why might the contents of pg_settings be different from what would be
in pg_file_settings, apart from the
On Sat, Jan 31, 2015 at 3:20 PM, Sawada Masahiko sawada.m...@gmail.com wrote:
On Sat, Jan 31, 2015 at 2:00 PM, Sawada Masahiko sawada.m...@gmail.com
wrote:
On Sat, Jan 31, 2015 at 4:56 AM, Tom Lane t...@sss.pgh.pa.us wrote:
David Johnston david.g.johns...@gmail.com writes:
On Fri, Jan 30,
On Sat, Jan 31, 2015 at 2:00 PM, Sawada Masahiko sawada.m...@gmail.com wrote:
On Sat, Jan 31, 2015 at 4:56 AM, Tom Lane t...@sss.pgh.pa.us wrote:
David Johnston david.g.johns...@gmail.com writes:
On Fri, Jan 30, 2015 at 12:05 PM, David Fetter da...@fetter.org wrote:
Why might the contents of
On Tue, Jan 27, 2015 at 3:34 AM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Jan 22, 2015 at 5:19 PM, Tom Lane t...@sss.pgh.pa.us wrote:
David Johnston david.g.johns...@gmail.com writes:
On Thu, Jan 22, 2015 at 3:04 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Is that a requirement, and if so
On Fri, Jan 23, 2015 at 4:36 AM, Jim Nasby jim.na...@bluetreble.com wrote:
Would this view have a row for every option in a config file? IE: if you set
something in both postgresql.conf and postgresql.auto.conf, would it show up
twice? I think it should, and that there should be a way to see
Sawada Masahiko sawada.m...@gmail.com writes:
As per discussion
http://www.postgresql.org/message-id/cad21aodkds8oqbr199wwrcp7fidvow6bbb+cgdwqhuf+gx_...@mail.gmail.com,
I would like to proposal new view like pg_file_settings to know detail
of config file via SQL.
- Background
In 9.4
Tom Lane-2 wrote
regression=# alter system reset timezone;
ALTER SYSTEM
regression=# select pg_reload_conf();
How does someone know that performing the above commands will result in the
TimeZone setting being changed from Asia/Shanghai to US/Eastern?
David J.
--
View this message in
On Thu, Jan 22, 2015 at 3:04 PM, Tom Lane t...@sss.pgh.pa.us wrote:
David G Johnston david.g.johns...@gmail.com writes:
Tom Lane-2 wrote
regression=# alter system reset timezone;
ALTER SYSTEM
regression=# select pg_reload_conf();
How does someone know that performing the above
David G Johnston david.g.johns...@gmail.com writes:
Tom Lane-2 wrote
regression=# alter system reset timezone;
ALTER SYSTEM
regression=# select pg_reload_conf();
How does someone know that performing the above commands will result in the
TimeZone setting being changed from Asia/Shanghai to
David Johnston david.g.johns...@gmail.com writes:
On Thu, Jan 22, 2015 at 3:04 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Is that a requirement, and if so why? Because this proposal doesn't
guarantee any such knowledge AFAICS.
âThe proposal provides for SQL access to all possible sources of
On Thu, Jan 22, 2015 at 3:19 PM, Tom Lane t...@sss.pgh.pa.us wrote:
David Johnston david.g.johns...@gmail.com writes:
On Thu, Jan 22, 2015 at 3:04 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Is that a requirement, and if so why? Because this proposal doesn't
guarantee any such knowledge
On Fri, Jan 23, 2015 at 3:49 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I know what the proposal is. What I am questioning is the use-case that
justifies having us build and support all this extra mechanism. How often
does anyone need to know what the next down variable value would be?
I would
On 01/22/2015 02:09 PM, David Johnston wrote:
The proposal provides for SQL access to all possible sources of
variable value setting and, ideally, a means of ordering them in
priority order, so that a search for TimeZone would return two records,
one for postgresql.auto.conf and one for
On 1/22/15 11:13 AM, Sawada Masahiko wrote:
Hi,
As per discussion
http://www.postgresql.org/message-id/cad21aodkds8oqbr199wwrcp7fidvow6bbb+cgdwqhuf+gx_...@mail.gmail.com,
I would like to proposal new view like pg_file_settings to know detail
of config file via SQL.
- Background
In 9.4
Hi,
As per discussion
http://www.postgresql.org/message-id/cad21aodkds8oqbr199wwrcp7fidvow6bbb+cgdwqhuf+gx_...@mail.gmail.com,
I would like to proposal new view like pg_file_settings to know detail
of config file via SQL.
- Background
In 9.4 postgresql.auto.conf is added to support ALTER SYSTEM
54 matches
Mail list logo
