Thread: Open items
Here are the open items. I think once they are resolved we can head into beta:pg_dump multiple -t (?)PITR backup status filewin32 binary version stampsserver logging process (?)pg_autovacuumintegration (in queue)pg_dump fixes (in queue) Does anyone have any more? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
> Here are the open items. I think once they are resolved we can head > into beta: > > pg_dump multiple -t (?) > PITR backup status file > win32 binary version stamps > server logging process (?) > pg_autovacuum integration (in queue) > pg_dump fixes (in queue) > > Does anyone have any more? win32 signal safe socket handler win32 query cancel in psql (?) Merlin
> -----Original Message----- > From: pgsql-hackers-owner@postgresql.org > [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Bruce Momjian > Sent: 02 August 2004 20:36 > To: PostgreSQL-development > Subject: [HACKERS] Open items > > > win32 binary version stamps Magnus has just gone on holiday for a couple of weeks but before he left he did tell me he'd submitted what was hopefully the final patch for this. I haven't seen it yet though - is it stuck in the queue? Regards, Dave.
Unless he's posted from an address that I dont' recognize, it isn't in the queue ... at least not for approval ... On Mon, 2 Aug 2004, Dave Page wrote: > > >> -----Original Message----- >> From: pgsql-hackers-owner@postgresql.org >> [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Bruce Momjian >> Sent: 02 August 2004 20:36 >> To: PostgreSQL-development >> Subject: [HACKERS] Open items >> >> >> win32 binary version stamps > > Magnus has just gone on holiday for a couple of weeks but before he left > he did tell me he'd submitted what was hopefully the final patch for > this. I haven't seen it yet though - is it stuck in the queue? > > Regards, Dave. > > ---------------------------(end of broadcast)--------------------------- > TIP 7: don't forget to increase your free space map settings > ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
> -----Original Message----- > From: Marc G. Fournier [mailto:scrappy@postgresql.org] > Sent: 02 August 2004 21:25 > To: Dave Page > Cc: Bruce Momjian; PostgreSQL-development > Subject: Re: [HACKERS] Open items > > > Unless he's posted from an address that I dont' recognize, it > isn't in the queue ... at least not for approval ... :-( OK, thanks for looking. Regards, Dave
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Here are the open items. I think once they are resolved we can head
> into beta:
> ...
> Does anyone have any more?
contrib/dbsize doesn't even compile, and I'm still of the opinion that
oid2name is going to be pretty useless if it doesn't know about
tablespaces.
FWIW, the binary-version-stamp issue did not strike me as something
that has to be fixed before beta.
regards, tom lane
"Merlin Moncure" <merlin.moncure@rcsonline.com> writes:
>> Does anyone have any more?
> win32 signal safe socket handler
I thought that was solved long ago?
> win32 query cancel in psql (?)
What's the issue here?
regards, tom lane
On Mon, 2004-08-02 at 12:35, Bruce Momjian wrote: > Does anyone have any more? >From reading the lists it seems like most of PITR is in. However, I can't find any docs for it so I don't know how I'd test it. I downloaded the latest snapshot and don't immediately see anything about PITR. Regards,Jeff Davis
OK, added. These items are not required for beta. --------------------------------------------------------------------------- Merlin Moncure wrote: > > Here are the open items. I think once they are resolved we can head > > into beta: > > > > pg_dump multiple -t (?) > > PITR backup status file > > win32 binary version stamps > > server logging process (?) > > pg_autovacuum integration (in queue) > > pg_dump fixes (in queue) > > > > Does anyone have any more? > > win32 signal safe socket handler > win32 query cancel in psql (?) > > Merlin > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Here are the open items. I think once they are resolved we can head > > into beta: > > ... > > Does anyone have any more? > > contrib/dbsize doesn't even compile, and I'm still of the opinion that > oid2name is going to be pretty useless if it doesn't know about > tablespaces. Added to open items. > > FWIW, the binary-version-stamp issue did not strike me as something > that has to be fixed before beta. Yea, I was unclear. They all don't need to be completed for beta. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Jeff Davis wrote: > On Mon, 2004-08-02 at 12:35, Bruce Momjian wrote: > > Does anyone have any more? > > >From reading the lists it seems like most of PITR is in. However, I > can't find any docs for it so I don't know how I'd test it. I downloaded > the latest snapshot and don't immediately see anything about PITR. Yep, PITR docs is an open item. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Tom Lane wrote: > "Merlin Moncure" <merlin.moncure@rcsonline.com> writes: > >> Does anyone have any more? > > > win32 signal safe socket handler > > I thought that was solved long ago? > > > win32 query cancel in psql (?) > > What's the issue here? I thought these were both solved a long ago but I kept them on the list. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Bruce Momjian wrote: > Jeff Davis wrote: > >>On Mon, 2004-08-02 at 12:35, Bruce Momjian wrote: >> >>>Does anyone have any more? >> >>>From reading the lists it seems like most of PITR is in. However, I >>can't find any docs for it so I don't know how I'd test it. I downloaded >>the latest snapshot and don't immediately see anything about PITR. > > > Yep, PITR docs is an open item. And is really needed because we can not play/experiment/test it without instructions... Regards Gaetano Mendola
Bruce Momjian wrote: > Tom Lane wrote: >>contrib/dbsize doesn't even compile, and I'm still of the opinion that >>oid2name is going to be pretty useless if it doesn't know about >>tablespaces. > > > Added to open items. The patch I posted is now at http://cvs.pgadmin.org/cgi-bin/viewcvs.cgi/pgadmin-tools/support/size.c?rev=HEAD Regards, Andreas
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Here are the open items. I think once they are resolved we can head > into beta: >... > Does anyone have any more? Two more: It`s not a beta-blocker, but I still need to fix the postgresql.conf.sample file to not use all those commented-out values. Unfortunately, I have not had time to do this. If someone could take of this, it would be most appreciated. See Tom`s notes on some issues involved: http://archives.postgresql.org/pgsql-patches/2004-07/msg00178.php Another reason to make sure this makes it into 8.0 is so that the new group of users does not see the format of the file change from 8.0 to 8.1, but can start right away with the more intuitive format. Second, Jan promised at OSCON to fix up server-side prepare so it actually works even if you do not have the exact types to pass in. I presume you will then be able to do something like this: PREPARE mystatement AS SELECT * FROM pg_class WHERE relanem = $1 which will make driver writers very, very happy. - -- Greg Sabino Mullane greg@turnstep.com PGP Key: 0x14964AC8 200408021700 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) iD8DBQFBD5ePvJuQZxSWSsgRAmoGAKCwXAzTPIkvco7720ngJG+QeuYdUwCfQkAp /Jqkq/L2UlG7C7KhmsIVFZs= =FA/T -----END PGP SIGNATURE-----
"Greg Sabino Mullane" <greg@turnstep.com> writes:
> Second, Jan promised at OSCON to fix up server-side prepare so it actually
> works even if you do not have the exact types to pass in. I presume you
> will then be able to do something like this:
> PREPARE mystatement AS SELECT * FROM pg_class WHERE relanem = $1
> which will make driver writers very, very happy.
Why would a driver writer care? He can use the Prepare protocol
message, which already can do the above --- and more to the point,
there's already a way for him to *find out* what types were resolved.
There is no way for the SQL-level PREPARE command to provide info
about how types were resolved, so I'm not in favor of hacking the
SQL command this way.
regards, tom lane
Jan Wieck <JanWieck@Yahoo.com> writes:
> Having done something similar for the SPI manager once, so that
> parameters can have unknown type and the code calling SPI_prepare() will
> find the chosen types in the type array, so that the code calling
> SPI_execp() can do the appropriate type casting, my idea is that
> preparing a statement does the same and exec prepared actually accepts
> unknown type arguments and calls the typein function before running the
> plan. However, I still need to look at the code ...
This is already *done*. All we need is to devise a reasonable API for
libpq to provide access to the V3-protocol Prepare message. I suspect
that we'd want it to bundle a Prepare and a Describe Statement
operation, so that the user would get back the list of actual argument
types in the same call that issues the prepare. But I haven't thought
it through in detail.
> If this is doable that way, we could log it as an open issue that needs
> to be finished for release.
[ shrug ] Arguably it was something that should have been done for 7.4.
If someone wants to step up to the plate now, I won't stand in the way.
regards, tom lane
On Tuesday 03 August 2004 08:18 am, Tom Lane wrote: > "Greg Sabino Mullane" <greg@turnstep.com> writes: > > Second, Jan promised at OSCON to fix up server-side prepare so it > > actually works even if you do not have the exact types to pass in. I > > presume you will then be able to do something like this: > > PREPARE mystatement AS SELECT * FROM pg_class WHERE relanem = $1 > > which will make driver writers very, very happy. > > Why would a driver writer care? He can use the Prepare protocol > message, which already can do the above --- and more to the point, > there's already a way for him to *find out* what types were resolved. > There is no way for the SQL-level PREPARE command to provide info > about how types were resolved, so I'm not in favor of hacking the > SQL command this way. > Quoth the manual (7.4):Presently, prepared statements for use with PQexecPrepared must be set up by executing an SQL PREPARE command, which is typically sent with PQexec (though any of libpq's query-submission functions may be used). A lower-level interface for preparing statements may be offered in a future release. Does the new, 8.0 libpq have an interface to the prepare protocol message? -- Jonathan Gardner jgardner@jonathangardner.net
On Tuesday 03 August 2004 11:46 am, Tom Lane wrote:
> Jan Wieck <JanWieck@Yahoo.com> writes:
> > Having done something similar for the SPI manager once, so that
> > parameters can have unknown type and the code calling SPI_prepare()
> > will find the chosen types in the type array, so that the code calling
> > SPI_execp() can do the appropriate type casting, my idea is that
> > preparing a statement does the same and exec prepared actually accepts
> > unknown type arguments and calls the typein function before running the
> > plan. However, I still need to look at the code ...
>
> This is already *done*. All we need is to devise a reasonable API for
> libpq to provide access to the V3-protocol Prepare message. I suspect
> that we'd want it to bundle a Prepare and a Describe Statement
> operation, so that the user would get back the list of actual argument
> types in the same call that issues the prepare. But I haven't thought
> it through in detail.
>
> > If this is doable that way, we could log it as an open issue that needs
> > to be finished for release.
>
> [ shrug ] Arguably it was something that should have been done for 7.4.
> If someone wants to step up to the plate now, I won't stand in the way.
>
As far as API, how about this: (My C is rusty...)
typedef struct PGpreparedStmt { char *name, char *stmt, int nParams, Oid *paramTypes,
} PGpreparedStmt;
PGpreparedStmt *PQprepare(PGconn *, char *name, char *stmt);
We could make the PGpreparedStmt struct opaque to the client (like PGresult
and PGconn) and provide accessor functions.
const char *PQpreparedStmtName(const PGpreparedStmt *);
const char *PQpreparedStmtStmt(const PGpreparedStmt *);
int PQpreparedStmtNParams(const PGpreparedStmt *);
const Oid *PQpreparedStmtParamTypes(const PGpreparedStmt *);
Question: Can we handle asynchronous prepares? (I think we could follow the
notifies method - it just magically picks it up while you consumeInput.)
int PQsendPrepare(PGconn *, char *name, char *stmt);
PGpreparedStmt *PQgetPrepare(PGconn *);
The naming could be better. I can't think of any good alternatives right
now.
I'll look into how to actually implement this at home tonight.
--
Jonathan Gardner
jgardner@jonathangardner.net
> It`s not a beta-blocker, but I still need to fix the postgresql.conf.sample > file to not use all those commented-out values. Unfortunately, I have not > had time to do this. If someone could take of this, it would be most > appreciated. See Tom`s notes on some issues involved: > > http://archives.postgresql.org/pgsql-patches/2004-07/msg00178.php > > Another reason to make sure this makes it into 8.0 is so that the new > group of users does not see the format of the file change from 8.0 to 8.1, > but can start right away with the more intuitive format. This is too involved a change at this stage. I don't expect postgresql.conf to change any more from 7.4->8.0 than from 8.0->8.1 so I don't see why this is more critical for this release, and it has too many open issues. > Second, Jan promised at OSCON to fix up server-side prepare so it actually > works even if you do not have the exact types to pass in. I presume you > will then be able to do something like this: > > PREPARE mystatement AS SELECT * FROM pg_class WHERE relanem = $1 > > which will make driver writers very, very happy. Promising does not mean it will get into CVS. I am not in favor of doing any of these things for 8.0. We are far past feature freeze. If someone wants these, they are going to have to make a persuasive argument to the community. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
First of all "promised at OSCON to fix" is a bit exaggerated. I said I will look into the issue and see what can be done. Having done something similar for the SPI manager once, so that parameters can have unknown type and the code calling SPI_prepare() will find the chosen types in the type array, so that the code calling SPI_execp() can do the appropriate type casting, my idea is that preparing a statement does the same and exec prepared actually accepts unknown type arguments and calls the typein function before running the plan. However, I still need to look at the code ... If this is doable that way, we could log it as an open issue that needs to be finished for release. Jan On 8/3/2004 1:18 PM, Jonathan Gardner wrote: > On Tuesday 03 August 2004 08:18 am, Tom Lane wrote: >> "Greg Sabino Mullane" <greg@turnstep.com> writes: >> > Second, Jan promised at OSCON to fix up server-side prepare so it >> > actually works even if you do not have the exact types to pass in. I >> > presume you will then be able to do something like this: >> > PREPARE mystatement AS SELECT * FROM pg_class WHERE relanem = $1 >> > which will make driver writers very, very happy. >> >> Why would a driver writer care? He can use the Prepare protocol >> message, which already can do the above --- and more to the point, >> there's already a way for him to *find out* what types were resolved. >> There is no way for the SQL-level PREPARE command to provide info >> about how types were resolved, so I'm not in favor of hacking the >> SQL command this way. >> > > Quoth the manual (7.4): > Presently, prepared statements for use with PQexecPrepared must be set up > by executing an SQL PREPARE command, which is typically sent with PQexec > (though any of libpq's query-submission functions may be used). A > lower-level interface for preparing statements may be offered in a future > release. > > Does the new, 8.0 libpq have an interface to the prepare protocol message? > -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
Tom Lane wrote: > Jan Wieck <JanWieck@Yahoo.com> writes: > > Having done something similar for the SPI manager once, so that > > parameters can have unknown type and the code calling SPI_prepare() will > > find the chosen types in the type array, so that the code calling > > SPI_execp() can do the appropriate type casting, my idea is that > > preparing a statement does the same and exec prepared actually accepts > > unknown type arguments and calls the typein function before running the > > plan. However, I still need to look at the code ... > > This is already *done*. All we need is to devise a reasonable API for > libpq to provide access to the V3-protocol Prepare message. I suspect > that we'd want it to bundle a Prepare and a Describe Statement > operation, so that the user would get back the list of actual argument > types in the same call that issues the prepare. But I haven't thought > it through in detail. > > > If this is doable that way, we could log it as an open issue that needs > > to be finished for release. > > [ shrug ] Arguably it was something that should have been done for 7.4. > If someone wants to step up to the plate now, I won't stand in the way. Agreed. I will add it to the open items list. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 03 August 2004 12:12 pm, Jonathan Gardner wrote: > I'll look into how to actually implement this at home tonight. Well, it's two nights later but I think I made some headway. I discovered the joy that is backend/tcop/postgres.c. I discovered that's were all the messages are dispatched. The two messages that Tom and others have been talking about are 'P' and 'D'. 'P' will prepare a statement. FE supplies the statement name (null is ok, it seems), the query, and the number of params and the param Oids. Well, except if you look at parse_analyze_varparams it seems that it *ignores* the numParams and paramTypes passed in. (I could be reading this wrong, so correct me.) It seems like for 'P' we should only be sending '0' for numParams and NULL for paramTypes. I don't see a scenario where sending anything else is useful, because parse_analyse_varparams practically ignores it. (Why do we even have to send these?) The response from 'P' is an empty message. For 'D', there are two routes. One is 'S' = describe a statement, the other is 'P' describe a portal. I'm not clear what the difference is. based on stuff I've seen here, it seems that 'S' is prepared statments, and 'P' is for cursors. The second argument is the statement name (or the cursor name) It returns two things. First comes the parameters. The code is 't', followed by the list length and the list of param types (Oids). Next comes the RowDescription, which it seems is used elsewhere. (let me guess - - for queries?) So the implementation of PQprepare would look something like this. (1) Send a 'P' message with the statmenet name and the query. Send 0 for nParams and Null for paramTypes. (2) Wait for an empty message. (3) Send a 'D' 'S' <statement name> message. (4) Wait for a response. (5) Take the parameters and put it into a struct. Return a reference to that struct. (6) Discard the RowDescription as no one will be using them. Comments on my rough outline and novice understanding accepted. I'll start coding soon unless there are objections. - -- Jonathan Gardner jgardner@jonathangardner.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFBEdsCqp6r/MVGlwwRAk0YAKCU++UecV2oqJz77tfXGeck5xu3pQCgoQX5 kLHtQ/9XJrRjtmubohQl0Zk= =U2Oa -----END PGP SIGNATURE-----
"Jonathan M. Gardner" <jgardner@jonathangardner.net> writes:
> except if you look at parse_analyze_varparams it seems that it *ignores*
> the numParams and paramTypes passed in. (I could be reading this wrong,
> so correct me.)
You're reading it wrong. That array is both an input and an output parameter.
regards, tom lane
On Thursday 05 August 2004 06:51 am, Tom Lane wrote: > "Jonathan M. Gardner" <jgardner@jonathangardner.net> writes: > > except if you look at parse_analyze_varparams it seems that it > > *ignores* the numParams and paramTypes passed in. (I could be reading > > this wrong, so correct me.) > > You're reading it wrong. That array is both an input and an output > parameter. > I'm trying to understand the reasoning behind it, and so let me ask a few questions. (1) What's the purpose of specifying the params if it is going to figure it out on its own? (2) What happens when I specify a different number of params than what is in the query string?(3 params in query, but 4 specified, or 2 params in query, but 1 specified.) (2) How do I specify something like this:1. Param 1 is an int.2. Param 2 is unknown - figure it out.3. Param 3 is a varchar. Does it even make sense to specify something like that? If these questions are answered by a discussion thread from a while back, I'd appreciate pointers. Thanks for your time Tom and others, I'm enjoying this and remembering C all at the same time. -- Jonathan Gardner jgardner@jonathangardner.net
Jonathan Gardner <jgardner@jonathangardner.net> writes:
> (1) What's the purpose of specifying the params if it is going to figure it
> out on its own?
It may not be able to pick an unambiguous type for an unspecified param.
Consider for instance "SELECT abs($1)". There isn't any principled way
to pick which of the abs() functions is meant.
> (2) What happens when I specify a different number of params than what is in
> the query string?(3 params in query, but 4 specified, or 2 params in query,
> but 1 specified.)
The former case: the param goes unused; the latter: you get an error.
> (2) How do I specify something like this:
> 1. Param 1 is an int.
> 2. Param 2 is unknown - figure it out.
> 3. Param 3 is a varchar.
23, 0, 1043 ...
regards, tom lane
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> It`s not a beta-blocker, but I still need to fix the postgresql.conf.sample >> file to not use all those commented-out values. Unfortunately, I have not >> had time to do this. If someone could take of this, it would be most >> appreciated. See Tom`s notes on some issues involved: >> >> http://archives.postgresql.org/pgsql-patches/2004-07/msg00178.php >> >> Another reason to make sure this makes it into 8.0 is so that the new >> group of users does not see the format of the file change from 8.0 to 8.1, >> but can start right away with the more intuitive format. > This is too involved a change at this stage. I don't expect > postgresql.conf to change any more from 7.4->8.0 than from 8.0->8.1 so I > don't see why this is more critical for this release, and it has too > many open issues. Tom's post linked above seems to indicate it might be accepted, but I will certainly yield to Core's decision. I'm still hoping someone else will step up to the plate and tackle this: I feel that it would be nice not to confuse a whole new group of users with commented-out defaults which may or may not have a relation to the actual setttings. :) - -- Greg Sabino Mullane greg@turnstep.com PGP Key: 0x14964AC8 200408052239 -----BEGIN PGP SIGNATURE----- iD8DBQFBEu+WvJuQZxSWSsgRArFoAKD9ZwS6aRk1iONGvsJEov6UJLiAhQCgjNv3 lGz6CeH9eTzghiGJltj16IA= =K1QP -----END PGP SIGNATURE-----
Greg Sabino Mullane wrote: [ There is text before PGP section. ] > [ PGP not available, raw data follows ] > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > >> It`s not a beta-blocker, but I still need to fix the postgresql.conf.sample > >> file to not use all those commented-out values. Unfortunately, I have not > >> had time to do this. If someone could take of this, it would be most > >> appreciated. See Tom`s notes on some issues involved: > >> > >> http://archives.postgresql.org/pgsql-patches/2004-07/msg00178.php > >> > >> Another reason to make sure this makes it into 8.0 is so that the new > >> group of users does not see the format of the file change from 8.0 to 8.1, > >> but can start right away with the more intuitive format. > > > This is too involved a change at this stage. I don't expect > > postgresql.conf to change any more from 7.4->8.0 than from 8.0->8.1 so I > > don't see why this is more critical for this release, and it has too > > many open issues. > > Tom's post linked above seems to indicate it might be accepted, but I > will certainly yield to Core's decision. I'm still hoping someone else > will step up to the plate and tackle this: I feel that it would be > nice not to confuse a whole new group of users with commented-out > defaults which may or may not have a relation to the actual setttings. :) Well, I haven't seen any of the research requested by Tom, and with beta a few days away, I don't see it happening in time. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Added to TODO: * Remove comments on postgresql.conf variables --------------------------------------------------------------------------- Bruce Momjian wrote: > Greg Sabino Mullane wrote: > [ There is text before PGP section. ] > > > [ PGP not available, raw data follows ] > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > > > >> It`s not a beta-blocker, but I still need to fix the postgresql.conf.sample > > >> file to not use all those commented-out values. Unfortunately, I have not > > >> had time to do this. If someone could take of this, it would be most > > >> appreciated. See Tom`s notes on some issues involved: > > >> > > >> http://archives.postgresql.org/pgsql-patches/2004-07/msg00178.php > > >> > > >> Another reason to make sure this makes it into 8.0 is so that the new > > >> group of users does not see the format of the file change from 8.0 to 8.1, > > >> but can start right away with the more intuitive format. > > > > > This is too involved a change at this stage. I don't expect > > > postgresql.conf to change any more from 7.4->8.0 than from 8.0->8.1 so I > > > don't see why this is more critical for this release, and it has too > > > many open issues. > > > > Tom's post linked above seems to indicate it might be accepted, but I > > will certainly yield to Core's decision. I'm still hoping someone else > > will step up to the plate and tackle this: I feel that it would be > > nice not to confuse a whole new group of users with commented-out > > defaults which may or may not have a relation to the actual setttings. :) > > Well, I haven't seen any of the research requested by Tom, and with beta > a few days away, I don't see it happening in time. > > -- > Bruce Momjian | http://candle.pha.pa.us > pgman@candle.pha.pa.us | (610) 359-1001 > + If your life is a hard drive, | 13 Roberts Road > + Christ can be your backup. | Newtown Square, Pennsylvania 19073 > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Is this the proper item description?* Remove comments on postgresql.conf variables By removing comments we prevent the confusionthat commenting a line returns a modified value to its default, which it does not. --------------------------------------------------------------------------- Bruce Momjian wrote: > > Added to TODO: > > * Remove comments on postgresql.conf variables > > > --------------------------------------------------------------------------- > > Bruce Momjian wrote: > > Greg Sabino Mullane wrote: > > [ There is text before PGP section. ] > > > > > [ PGP not available, raw data follows ] > > > -----BEGIN PGP SIGNED MESSAGE----- > > > Hash: SHA1 > > > > > > > > > >> It`s not a beta-blocker, but I still need to fix the postgresql.conf.sample > > > >> file to not use all those commented-out values. Unfortunately, I have not > > > >> had time to do this. If someone could take of this, it would be most > > > >> appreciated. See Tom`s notes on some issues involved: > > > >> > > > >> http://archives.postgresql.org/pgsql-patches/2004-07/msg00178.php > > > >> > > > >> Another reason to make sure this makes it into 8.0 is so that the new > > > >> group of users does not see the format of the file change from 8.0 to 8.1, > > > >> but can start right away with the more intuitive format. > > > > > > > This is too involved a change at this stage. I don't expect > > > > postgresql.conf to change any more from 7.4->8.0 than from 8.0->8.1 so I > > > > don't see why this is more critical for this release, and it has too > > > > many open issues. > > > > > > Tom's post linked above seems to indicate it might be accepted, but I > > > will certainly yield to Core's decision. I'm still hoping someone else > > > will step up to the plate and tackle this: I feel that it would be > > > nice not to confuse a whole new group of users with commented-out > > > defaults which may or may not have a relation to the actual setttings. :) > > > > Well, I haven't seen any of the research requested by Tom, and with beta > > a few days away, I don't see it happening in time. > > > > -- > > Bruce Momjian | http://candle.pha.pa.us > > pgman@candle.pha.pa.us | (610) 359-1001 > > + If your life is a hard drive, | 13 Roberts Road > > + Christ can be your backup. | Newtown Square, Pennsylvania 19073 > > > > ---------------------------(end of broadcast)--------------------------- > > TIP 4: Don't 'kill -9' the postmaster > > > > -- > Bruce Momjian | http://candle.pha.pa.us > pgman@candle.pha.pa.us | (610) 359-1001 > + If your life is a hard drive, | 13 Roberts Road > + Christ can be your backup. | Newtown Square, Pennsylvania 19073 > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Hrmmm, stupid question here, but why not just change hte postgresql.conf to be those variables that *are* changed from the default, with a simple comment pointing to the documention for the rest? the benefit of that is that at lesat the documentation has fuller descriptions of what the variables are for ... *that* could be easily done after beta ... On Fri, 6 Aug 2004, Bruce Momjian wrote: > > Is this the proper item description? > > * Remove comments on postgresql.conf variables > > By removing comments we prevent the confusion that commenting a line > returns a modified value to its default, which it does not. > > --------------------------------------------------------------------------- > > Bruce Momjian wrote: >> >> Added to TODO: >> >> * Remove comments on postgresql.conf variables >> >> >> --------------------------------------------------------------------------- >> >> Bruce Momjian wrote: >>> Greg Sabino Mullane wrote: >>> [ There is text before PGP section. ] >>>> >>> [ PGP not available, raw data follows ] >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA1 >>>> >>>> >>>>>> It`s not a beta-blocker, but I still need to fix the postgresql.conf.sample >>>>>> file to not use all those commented-out values. Unfortunately, I have not >>>>>> had time to do this. If someone could take of this, it would be most >>>>>> appreciated. See Tom`s notes on some issues involved: >>>>>> >>>>>> http://archives.postgresql.org/pgsql-patches/2004-07/msg00178.php >>>>>> >>>>>> Another reason to make sure this makes it into 8.0 is so that the new >>>>>> group of users does not see the format of the file change from 8.0 to 8.1, >>>>>> but can start right away with the more intuitive format. >>>> >>>>> This is too involved a change at this stage. I don't expect >>>>> postgresql.conf to change any more from 7.4->8.0 than from 8.0->8.1 so I >>>>> don't see why this is more critical for this release, and it has too >>>>> many open issues. >>>> >>>> Tom's post linked above seems to indicate it might be accepted, but I >>>> will certainly yield to Core's decision. I'm still hoping someone else >>>> will step up to the plate and tackle this: I feel that it would be >>>> nice not to confuse a whole new group of users with commented-out >>>> defaults which may or may not have a relation to the actual setttings. :) >>> >>> Well, I haven't seen any of the research requested by Tom, and with beta >>> a few days away, I don't see it happening in time. >>> >>> -- >>> Bruce Momjian | http://candle.pha.pa.us >>> pgman@candle.pha.pa.us | (610) 359-1001 >>> + If your life is a hard drive, | 13 Roberts Road >>> + Christ can be your backup. | Newtown Square, Pennsylvania 19073 >>> >>> ---------------------------(end of broadcast)--------------------------- >>> TIP 4: Don't 'kill -9' the postmaster >>> >> >> -- >> Bruce Momjian | http://candle.pha.pa.us >> pgman@candle.pha.pa.us | (610) 359-1001 >> + If your life is a hard drive, | 13 Roberts Road >> + Christ can be your backup. | Newtown Square, Pennsylvania 19073 >> > > -- > Bruce Momjian | http://candle.pha.pa.us > pgman@candle.pha.pa.us | (610) 359-1001 > + If your life is a hard drive, | 13 Roberts Road > + Christ can be your backup. | Newtown Square, Pennsylvania 19073 > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster > ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Marc G. Fournier wrote: > > Hrmmm, stupid question here, but why not just change hte postgresql.conf > to be those variables that *are* changed from the default, with a simple > comment pointing to the documention for the rest? the benefit of that is > that at lesat the documentation has fuller descriptions of what the > variables are for ... > > *that* could be easily done after beta ... Not sure why removing the comments is seen as good myself, but I think the idea was that if you comment out something and change the default, you assume that commenting it out returns it to the default, though it does not. I am unclear on your suggestion above. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
On Fri, 6 Aug 2004, Bruce Momjian wrote: > Marc G. Fournier wrote: >> >> Hrmmm, stupid question here, but why not just change hte postgresql.conf >> to be those variables that *are* changed from the default, with a simple >> comment pointing to the documention for the rest? the benefit of that is >> that at lesat the documentation has fuller descriptions of what the >> variables are for ... >> >> *that* could be easily done after beta ... > > Not sure why removing the comments is seen as good myself, but I think > the idea was that if you comment out something and change the default, > you assume that commenting it out returns it to the default, though it > does not. 'k, now you've totally confused me ... if you comment something out, and it doesn't return to the default, where does it go to? my understanding was that the 'beef' was that the defaults that are displayed on each of the variables in postgresql.conf file don't necessarily match the defaults compiled into the backend ... which, I *think* is what you meant in the above? :) Right now, if you install postgresql, there are various variables added/set in the postgresql.conf file (notably the stuff that Tom did with the shared memory buffer) ... with the rest being "what could be the default, but may not be" for the commented out variables ... my suggestion is to remove the commented out variables altogether, and change the file to something like: # # for a complete list of GUC variables, see ... # <put 'live/set' variables here> ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
If you change shared_buffers to 2000, remove the comment and reload, the variable is now 2000. If you comment out the variable and reload again, it is still 2000, not the default. --------------------------------------------------------------------------- Marc G. Fournier wrote: > On Fri, 6 Aug 2004, Bruce Momjian wrote: > > > Marc G. Fournier wrote: > >> > >> Hrmmm, stupid question here, but why not just change hte postgresql.conf > >> to be those variables that *are* changed from the default, with a simple > >> comment pointing to the documention for the rest? the benefit of that is > >> that at lesat the documentation has fuller descriptions of what the > >> variables are for ... > >> > >> *that* could be easily done after beta ... > > > > Not sure why removing the comments is seen as good myself, but I think > > the idea was that if you comment out something and change the default, > > you assume that commenting it out returns it to the default, though it > > does not. > > 'k, now you've totally confused me ... if you comment something out, and > it doesn't return to the default, where does it go to? > > my understanding was that the 'beef' was that the defaults that are > displayed on each of the variables in postgresql.conf file don't > necessarily match the defaults compiled into the backend ... which, I > *think* is what you meant in the above? :) > > Right now, if you install postgresql, there are various variables > added/set in the postgresql.conf file (notably the stuff that Tom did with > the shared memory buffer) ... with the rest being "what could be the > default, but may not be" for the commented out variables ... my suggestion > is to remove the commented out variables altogether, and change the file > to something like: > > # > # for a complete list of GUC variables, see ... > # > <put 'live/set' variables here> > > > ---- > Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) > Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664 > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Is this the proper item description?
> * Remove comments on postgresql.conf variables
It could easily be taken to mean removing this:
#authentication_timeout = 60 # 1-600, in seconds ^^^^^^^^^^^^^^^^^^^
rather than the leading #. I'd suggest
* Un-comment all variables in postgresql.conf
By not showing commented-out variables, we will discourage people from thinking that re-commenting a variable
returnsit to its default.
regards, tom lane
On Fri, 6 Aug 2004, Bruce Momjian wrote: > > If you change shared_buffers to 2000, remove the comment and reload, the > variable is now 2000. If you comment out the variable and reload again, > it is still 2000, not the default. Oh, weird ... and that isn't considered a bug? Definitely wouldn't be the behaviour I would have expected of any other server/daemon process ... now I can see where the confusion is arising :( > Marc G. Fournier wrote: >> On Fri, 6 Aug 2004, Bruce Momjian wrote: >> >>> Marc G. Fournier wrote: >>>> >>>> Hrmmm, stupid question here, but why not just change hte postgresql.conf >>>> to be those variables that *are* changed from the default, with a simple >>>> comment pointing to the documention for the rest? the benefit of that is >>>> that at lesat the documentation has fuller descriptions of what the >>>> variables are for ... >>>> >>>> *that* could be easily done after beta ... >>> >>> Not sure why removing the comments is seen as good myself, but I think >>> the idea was that if you comment out something and change the default, >>> you assume that commenting it out returns it to the default, though it >>> does not. >> >> 'k, now you've totally confused me ... if you comment something out, and >> it doesn't return to the default, where does it go to? >> >> my understanding was that the 'beef' was that the defaults that are >> displayed on each of the variables in postgresql.conf file don't >> necessarily match the defaults compiled into the backend ... which, I >> *think* is what you meant in the above? :) >> >> Right now, if you install postgresql, there are various variables >> added/set in the postgresql.conf file (notably the stuff that Tom did with >> the shared memory buffer) ... with the rest being "what could be the >> default, but may not be" for the commented out variables ... my suggestion >> is to remove the commented out variables altogether, and change the file >> to something like: >> >> # >> # for a complete list of GUC variables, see ... >> # >> <put 'live/set' variables here> >> >> >> ---- >> Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) >> Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664 >> > > -- > Bruce Momjian | http://candle.pha.pa.us > pgman@candle.pha.pa.us | (610) 359-1001 > + If your life is a hard drive, | 13 Roberts Road > + Christ can be your backup. | Newtown Square, Pennsylvania 19073 > ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
On Fri, 6 Aug 2004, Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: >> Is this the proper item description? > >> * Remove comments on postgresql.conf variables > > It could easily be taken to mean removing this: > > #authentication_timeout = 60 # 1-600, in seconds > ^^^^^^^^^^^^^^^^^^^ > > rather than the leading #. I'd suggest > > * Un-comment all variables in postgresql.conf > > By not showing commented-out variables, we will discourage > people from thinking that re-commenting a variable returns it > to its default. That works ... then it implies that there are just no defaults, which, IMHO, would definitely cause less confusion :) ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Done. --------------------------------------------------------------------------- Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Is this the proper item description? > > > * Remove comments on postgresql.conf variables > > It could easily be taken to mean removing this: > > #authentication_timeout = 60 # 1-600, in seconds > ^^^^^^^^^^^^^^^^^^^ > > rather than the leading #. I'd suggest > > * Un-comment all variables in postgresql.conf > > By not showing commented-out variables, we will discourage > people from thinking that re-commenting a variable returns it > to its default. > > regards, tom lane > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073