Thread: dropdb weirdness

dropdb weirdness

From
Geoffrey
Date:
So running the following command:

dropdb -p 5443 swr

I get:

dropdb: could not connect to database postgres: FATAL:  database
"postgres" does not exist

Why is it not 'seeing' the database name I'm passing to it?  Why is it
trying to drop a database named postgres??

--
Until later, Geoffrey

"I predict future happiness for America if they can prevent
the government from wasting the labors of the people under
the pretense of taking care of them."
- Thomas Jefferson

Re: dropdb weirdness

From
Merlin Moncure
Date:
On Tue, Jun 29, 2010 at 4:04 PM, Geoffrey <lists@serioustechnology.com> wrote:
> So running the following command:
>
> dropdb -p 5443 swr
>
> I get:
>
> dropdb: could not connect to database postgres: FATAL:  database "postgres"
> does not exist
>
> Why is it not 'seeing' the database name I'm passing to it?  Why is it
> trying to drop a database named postgres??

It's not. It's trying to log into the postgres database to execute the
command.   Try logging into the database via psql you want to issue
the 'drop database' sql FROM (usually template1 / postgres) and do the
drop database yourself. You can't drop the database you are logged in
to.

merlin

Re: dropdb weirdness

From
Adrian Klaver
Date:
On Tuesday 29 June 2010 1:04:27 pm Geoffrey wrote:
> So running the following command:
>
> dropdb -p 5443 swr
>
> I get:
>
> dropdb: could not connect to database postgres: FATAL:  database
> "postgres" does not exist
>
> Why is it not 'seeing' the database name I'm passing to it?  Why is it
> trying to drop a database named postgres??
>
> --

It needs to connect to the database cluster to run the DROP DATABASE command and
is trying to use the system database postgres. Did you drop the postgres
database? Does the user you are connecting as have the permissions to postgres?



--
Adrian Klaver
adrian.klaver@gmail.com

Re: dropdb weirdness

From
Tom Lane
Date:
Adrian Klaver <adrian.klaver@gmail.com> writes:
> On Tuesday 29 June 2010 1:04:27 pm Geoffrey wrote:
>> dropdb: could not connect to database postgres: FATAL:  database
>> "postgres" does not exist
>>
>> Why is it not 'seeing' the database name I'm passing to it?  Why is it
>> trying to drop a database named postgres??

> It needs to connect to the database cluster to run the DROP DATABASE command and
> is trying to use the system database postgres. Did you drop the postgres
> database? Does the user you are connecting as have the permissions to postgres?

"does not exist" is not a permissions problem ;-)

What I'm wondering is if this indicates use of 8.1 or later dropdb
script against a pre-8.1 server.  Before 8.1 there wasn't a postgres
database by default, and dropdb would instead try to connect to
template1.  You can work around this by forcing dropdb to connect to
an existing database name, but it'd probably be better to keep your
client tools in sync with the server version.

            regards, tom lane

Re: dropdb weirdness

From
Geoffrey
Date:
Tom Lane wrote:
> Adrian Klaver <adrian.klaver@gmail.com> writes:
>> On Tuesday 29 June 2010 1:04:27 pm Geoffrey wrote:
>>> dropdb: could not connect to database postgres: FATAL:  database
>>> "postgres" does not exist
>>>
>>> Why is it not 'seeing' the database name I'm passing to it?  Why is it
>>> trying to drop a database named postgres??
>
>> It needs to connect to the database cluster to run the DROP DATABASE command and
>> is trying to use the system database postgres. Did you drop the postgres
>> database? Does the user you are connecting as have the permissions to postgres?
>
> "does not exist" is not a permissions problem ;-)
>
> What I'm wondering is if this indicates use of 8.1 or later dropdb
> script against a pre-8.1 server.  Before 8.1 there wasn't a postgres
> database by default, and dropdb would instead try to connect to
> template1.  You can work around this by forcing dropdb to connect to
> an existing database name, but it'd probably be better to keep your
> client tools in sync with the server version.
>
>             regards, tom lane

I know the version of dropdb is 8.3.6.  There SHOULD be only one version
of postgres installed on this machine, but I will verify that tomorrow.
  This is a standard RHEL workstation running on a laptop.

The weird thing about this is, I've used this script on three other
machines just fine. Further, it worked on another database on this same
machine, but two others failed with this same error.

I'm instructing the user how to run the script remotely, so I don't have
eyes on what she's doing.  She says she is running it as the postgres
user.  I don't have access to her cluster, so I can't verify if the
postgres database is there, although I would expect it is as all these
machines were set up the same way.

She's offline for the day, so I'll catch up with her tomorrow and ask
her to list her databases in that cluster.

Thanks to all for the feedback.


--
Until later, Geoffrey

"I predict future happiness for America if they can prevent
the government from wasting the labors of the people under
the pretense of taking care of them."
- Thomas Jefferson

Re: dropdb weirdness

From
Steve Grey
Date:
Silly ideas, but is dropdb confusing the "postgres" user on the host and a database named "postgres"?  (does the 1st database the command was run on still exist?)  Does it do it right if the -U and -W switches are used?

Steve



On 29 June 2010 22:38, Geoffrey <lists@serioustechnology.com> wrote:
Tom Lane wrote:
Adrian Klaver <adrian.klaver@gmail.com> writes:
On Tuesday 29 June 2010 1:04:27 pm Geoffrey wrote:
dropdb: could not connect to database postgres: FATAL:  database
"postgres" does not exist

Why is it not 'seeing' the database name I'm passing to it?  Why is it
trying to drop a database named postgres??

It needs to connect to the database cluster to run the DROP DATABASE command and is trying to use the system database postgres. Did you drop the postgres database? Does the user you are connecting as have the permissions to postgres?

"does not exist" is not a permissions problem ;-)

What I'm wondering is if this indicates use of 8.1 or later dropdb
script against a pre-8.1 server.  Before 8.1 there wasn't a postgres
database by default, and dropdb would instead try to connect to
template1.  You can work around this by forcing dropdb to connect to
an existing database name, but it'd probably be better to keep your
client tools in sync with the server version.

                       regards, tom lane

I know the version of dropdb is 8.3.6.  There SHOULD be only one version of postgres installed on this machine, but I will verify that tomorrow.  This is a standard RHEL workstation running on a laptop.

The weird thing about this is, I've used this script on three other machines just fine. Further, it worked on another database on this same machine, but two others failed with this same error.

I'm instructing the user how to run the script remotely, so I don't have eyes on what she's doing.  She says she is running it as the postgres user.  I don't have access to her cluster, so I can't verify if the postgres database is there, although I would expect it is as all these machines were set up the same way.

She's offline for the day, so I'll catch up with her tomorrow and ask her to list her databases in that cluster.

Thanks to all for the feedback.



--
Until later, Geoffrey

"I predict future happiness for America if they can prevent
the government from wasting the labors of the people under
the pretense of taking care of them."
- Thomas Jefferson

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

#avg_ls_inline_popup { position:absolute; z-index:9999; padding: 0px 0px; margin-left: 0px; margin-top: 0px; width: 240px; overflow: hidden; word-wrap: break-word; color: black; font-size: 10px; text-align: left; line-height: 13px;}