dropdb weirdness
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
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 existWhy 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
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 existWhy 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
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 existWhy 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
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 existWhy 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
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:
Show quoted text
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 existWhy 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