On Fri, 18 Nov 2005 05:29 am, Tom Lane wrote:
> It does seem a bit inconsistent that psql wouldn't connect to the
> specified database in order to do -l, if one is specified.
> Anyone want to look and see if it's easy to change?

It also breaks the ability to psql -l against older installations: e.g. this
is psql 8.1 trying to list databases on a 8.0.3 DB server:

$ psql -l -hdev2 -dtemplate1
psql: FATAL: database "postgres" does not exist

I'm told we never promise to make \l and \d work across client/server
versions, but if this is related, it'd be nice if the fix made this work
again too.

Regards, Philip.
--

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

-----------------
Utiba Pty Ltd
This message has been scanned for viruses and
dangerous content by Utiba mail server and is
believed to be clean.


---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Andrew Dunstan wrote:

>>
>> It does seem a bit inconsistent that psql wouldn't connect to the
>> specified database in order to do -l, if one is specified.
>> Anyone want to look and see if it's easy to change?
>>
>>
>
>
> options.action == ACT_LIST_DB && options.dbname == NULL ?
> "postgres" : options.dbname
>

Tested, and worked fine.

Committed on Head and 8.1 branches.

cheers

andrew

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

I now notice that "pg_ctl -w start" fails if the postgres db is missing.
I am not sure that changing pg_ctl to use this rather than template1 was
a good thing, and it can't be overridden. I suggest we revert that
particular change - it seems to me to confer little to no benefit,
unlike the case with createdb etc.

cheers

andrew



Andrew Dunstan wrote:

>
>
> Andrew Dunstan wrote:
>
>>>
>>> It does seem a bit inconsistent that psql wouldn't connect to the
>>> specified database in order to do -l, if one is specified.
>>> Anyone want to look and see if it's easy to change?
>>>
>>>
>>
>>
>> options.action == ACT_LIST_DB && options.dbname == NULL ?
>> "postgres" : options.dbname
>>
>
> Tested, and worked fine.
>
> Committed on Head and 8.1 branches.
>
> cheers
>
> andrew
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
>

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Tom Lane wrote:

>Andrew Dunstan <andrew@dunslane.net> writes:
>
>
>>I now notice that "pg_ctl -w start" fails if the postgres db is missing.
>>I am not sure that changing pg_ctl to use this rather than template1 was
>>a good thing, and it can't be overridden. I suggest we revert that
>>particular change - it seems to me to confer little to no benefit,
>>unlike the case with createdb etc.
>>
>>
>
>pg_ctl -w is already incredibly fragile because it needs a working
>password-free login name. Rather than worrying about whether the
>database name exists, what we ought to do is invent the long-awaited
>"ping" extension to the postmaster protocol --- something that would
>just ask "are you up and ready to accept connections" without having
>to specify a valid user *or* database name.
>
>You can sort of do this today if you are willing to examine the error
>message that comes back from the postmaster, but I think it'd be cleaner
>to have an official protocol extension.
>
>


Actually, it looks like pg_ctl already does this:

if ((conn = PQsetdbLogin(NULL, portstr, NULL, NULL,
"postgres", NULL, NULL)) != NULL &&
(PQstatus(conn) == CONNECTION_OK ||
(strcmp(PQerrorMessage(conn),
PQnoPasswordSupplied) == 0)))
{
PQfinish(conn);
success = true;
break;
}


cheers

andrew


---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Andrew Dunstan <andrew@dunslane.net> writes:
> I now notice that "pg_ctl -w start" fails if the postgres db is missing.
> I am not sure that changing pg_ctl to use this rather than template1 was
> a good thing, and it can't be overridden. I suggest we revert that
> particular change - it seems to me to confer little to no benefit,
> unlike the case with createdb etc.

pg_ctl -w is already incredibly fragile because it needs a working
password-free login name. Rather than worrying about whether the
database name exists, what we ought to do is invent the long-awaited
"ping" extension to the postmaster protocol --- something that would
just ask "are you up and ready to accept connections" without having
to specify a valid user *or* database name.

You can sort of do this today if you are willing to examine the error
message that comes back from the postmaster, but I think it'd be cleaner
to have an official protocol extension.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

I never saw a followup to this. Is someone working on a ping protocol
extension, or should we revert pg_ctl to using template1 on the ground
that it does a poor man's ping anyway?

cheers

andrew

Andrew Dunstan wrote:

>
>
> Tom Lane wrote:
>
>> Andrew Dunstan <andrew@dunslane.net> writes:
>>
>>
>>> I now notice that "pg_ctl -w start" fails if the postgres db is
>>> missing. I am not sure that changing pg_ctl to use this rather than
>>> template1 was a good thing, and it can't be overridden. I suggest we
>>> revert that particular change - it seems to me to confer little to
>>> no benefit, unlike the case with createdb etc.
>>>
>>
>>
>> pg_ctl -w is already incredibly fragile because it needs a working
>> password-free login name. Rather than worrying about whether the
>> database name exists, what we ought to do is invent the long-awaited
>> "ping" extension to the postmaster protocol --- something that would
>> just ask "are you up and ready to accept connections" without having
>> to specify a valid user *or* database name.
>>
>> You can sort of do this today if you are willing to examine the error
>> message that comes back from the postmaster, but I think it'd be cleaner
>> to have an official protocol extension.
>>
>>
>
>
> Actually, it looks like pg_ctl already does this:
>
> if ((conn = PQsetdbLogin(NULL, portstr, NULL, NULL,
> "postgres", NULL, NULL)) != NULL &&
> (PQstatus(conn) == CONNECTION_OK ||
> (strcmp(PQerrorMessage(conn),
> PQnoPasswordSupplied) == 0)))
> {
> PQfinish(conn);
> success = true;
> break;
> }
>
>

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings