Alvaro Herrera wrote:
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
Hmm, I didn't recheck after Greg's patch, but in mine, it doesn't,
because the location is saved as reset location and restored when the
variable is reset. It worked fine in all cases I tested.
On Tue, 9 Sep 2008, Magnus Hagander wrote:
(I dropped the default stuff for now, as it doesn't seem that a
consensus has been reached on that topic.)
This is one of the reasons I suggested keeping that one as a separate
patch in the first place. The other main reason being that once it gets
Greg Smith wrote:
On Tue, 9 Sep 2008, Magnus Hagander wrote:
(I dropped the default stuff for now, as it doesn't seem that a
consensus has been reached on that topic.)
This is one of the reasons I suggested keeping that one as a separate
patch in the first place. The other main reason being
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
Hmm, I didn't recheck after Greg's patch, but in mine, it doesn't,
because the location is saved as reset location and restored when the
variable is reset. It worked fine in all cases I tested.
Hmm. Actually,
On Mon, 8 Sep 2008, Alvaro Herrera wrote:
(I dropped the default stuff for now, as it doesn't seem that a
consensus has been reached on that topic.)
I have multiple GUC-related projects that are all stalled waiting for that
capability to be added. The only thing there wasn't clear consensus
Greg Smith [EMAIL PROTECTED] wrote:
name | Recommended | Current | Min | Default | Max
-+-+-+---+-+-
wal_buffers | 1024kB | 64kB| 32 kB | 64 kB | 2048 MB
Personally, I would take the Min, Default, and Max to
On Thu, 4 Sep 2008, Kevin Grittner wrote:
Personally, I would take the Min, Default, and Max to mean what
Greg intends; it's the Current one that gives me pause.
That's the output of current_setting(name) which shows what it is right
now; no more, no less. See
On Tue, 2 Sep 2008, Tom Lane wrote:
How about having two new columns reset value and boot value?
Like it better than default value ...
It's being a bit pedantic at the expense of the user, but I don't really
care that much here. I exposed the boot_val and described it in the
Greg Smith [EMAIL PROTECTED] writes:
On Tue, 2 Sep 2008, Tom Lane wrote:
How about having two new columns reset value and boot value?
Like it better than default value ...
It's being a bit pedantic at the expense of the user, but I don't really
care that much here. I exposed the boot_val
On Wed, 3 Sep 2008, Tom Lane wrote:
Default value if the parameter is not explicitly set
If that statement were the truth, the whole truth, and nothing but the
truth, and if it didn't ignore the point about explicitly set WHERE?,
I'd be fine with it.
First question--how about if I changed
On Wed, 3 Sep 2008 16:04:12 -0400 (EDT)
Greg Smith [EMAIL PROTECTED] wrote:
Section question: with those changes, would it then be reasonable to
you to keep that column named default instead of giving it a less
common name?
You are adopting a very narrow mindset, which seems to be that
Joshua Drake [EMAIL PROTECTED] writes:
I guess I would ask, Who else would we be targeting this for?. DBAs
seem to be the only logical choice.
Regular users look at pg_settings too, you know. Maybe *you* only
get questions from DBAs...
regards, tom lane
--
Sent via
Greg Smith [EMAIL PROTECTED] writes:
First question--how about if I changed that description to read:
Default value used at server startup if the parameter is not explicitly
set?
... not otherwise set would probably be an accurate phrasing.
(I'm thinking of corner cases like stuff absorbed
Before I respond to Tom's comments, let me step back a second and add the
intro the deadline didn't leave me time for. There are two specific
things the bit I added to this GUC patch is aimed at:
1) Somebody has a postgresql.conf from a random source (saw it on the
Internet and pasted
On Wed, 3 Sep 2008, Tom Lane wrote:
Greg Smith [EMAIL PROTECTED] writes:
First question--how about if I changed that description to read:
Default value used at server startup if the parameter is not explicitly
set?
... not otherwise set would probably be an accurate phrasing.
(I'm
Alvaro Herrera [EMAIL PROTECTED] writes:
Greg just sent me this patch, augmenting the one I sent to add source
file and line to GUC vars; Greg's patch adds a column with the default
value of each var.
I haven't tested, but doesn't this lose the source-location information
if a setting acquired
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
I haven't tested, but doesn't this lose the source-location information
if a setting acquired from the config file is temporarily overridden via
SET (consider SET LOCAL, or a SET in a rolled-back xact)? It'll go to
NULL and not come
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Greg just sent me this patch, augmenting the one I sent to add source
file and line to GUC vars; Greg's patch adds a column with the default
value of each var.
I haven't tested, but doesn't this lose the source-location information
Greg just sent me this patch, augmenting the one I sent to add source
file and line to GUC vars; Greg's patch adds a column with the default
value of each var.
I forward it to -hackers to have a public Message-Id to link to in the
Commitfest page.
--
Alvaro Herrera
On Thursday 28 August 2008 13:08:58 Alvaro Herrera wrote:
Hi,
Here's a patch to add source file and line numbers to GUC variables.
Basically this makes pg_settings look like this:
snip
This should make life easier for tools trying to find the config file
each setting is from (and possibly
Robert Treat wrote:
On Thursday 28 August 2008 13:08:58 Alvaro Herrera wrote:
This should make life easier for tools trying to find the config file
each setting is from (and possibly edit it).
If I have read this patch right, anything commented out (aka all of our
default values) will
Hi,
Here's a patch to add source file and line numbers to GUC variables.
Basically this makes pg_settings look like this:
alvherre=# select name, setting, sourcefile, sourceline from pg_settings where
name like '%work%';
name | setting | sourcefile
This looks quite handy. Needs to have an update to the view-pg-settings
section of the docs before it gets applied though.
I'd also like to get the default boot_val for each parameter exposed,
similarly to how the min and max are available. That should be easy to do
using your changes as a
Greg Smith wrote:
This looks quite handy. Needs to have an update to the view-pg-settings
section of the docs before it gets applied though.
I'd also like to get the default boot_val for each parameter exposed,
similarly to how the min and max are available. That should be easy to
do
24 matches
Mail list logo
