Thread: Open items

Open items

From
Bruce Momjian
Date:
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
 


Re: Open items

From
"Merlin Moncure"
Date:
> 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


Re: Open items

From
"Dave Page"
Date:

> -----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.


Re: Open items

From
"Marc G. Fournier"
Date:
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


Re: Open items

From
"Dave Page"
Date:

> -----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


Re: Open items

From
Tom Lane
Date:
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


Re: Open items

From
Tom Lane
Date:
"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


Re: Open items

From
Jeff Davis
Date:
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



Re: Open items

From
Bruce Momjian
Date:
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
 


Re: Open items

From
Bruce Momjian
Date:
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
 


Re: Open items

From
Bruce Momjian
Date:
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
 


Re: Open items

From
Bruce Momjian
Date:
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
 


Re: Open items

From
Gaetano Mendola
Date:
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




Re: Open items

From
Andreas Pflug
Date:
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


Re: Open items

From
"Greg Sabino Mullane"
Date:
-----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-----




Re: Open items

From
Tom Lane
Date:
"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


Re: Open items

From
Tom Lane
Date:
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


Re: Open items

From
Jonathan Gardner
Date:
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


Re: Open items

From
Jonathan Gardner
Date:
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


Re: Open items

From
Bruce Momjian
Date:
> 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
 


Re: Open items

From
Jan Wieck
Date:
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 #


Re: Open items

From
Bruce Momjian
Date:
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
 


Re: Open items

From
"Jonathan M. Gardner"
Date:
-----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-----


Re: Open items

From
Tom Lane
Date:
"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


Re: Open items

From
Jonathan Gardner
Date:
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


Re: Open items

From
Tom Lane
Date:
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


Re: Open items

From
"Greg Sabino Mullane"
Date:
-----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-----




Re: Open items

From
Bruce Momjian
Date:
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
 


Re: Open items

From
Bruce Momjian
Date:
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
 


Re: Open items

From
Bruce Momjian
Date:
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
 


Re: Open items

From
"Marc G. Fournier"
Date:
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


Re: Open items

From
Bruce Momjian
Date:
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
 


Re: Open items

From
"Marc G. Fournier"
Date:
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


Re: Open items

From
Bruce Momjian
Date:
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
 


Re: Open items

From
Tom Lane
Date:
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


Re: Open items

From
"Marc G. Fournier"
Date:
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


Re: Open items

From
"Marc G. Fournier"
Date:
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


Re: Open items

From
Bruce Momjian
Date:
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