Skip site navigation (1) Skip section navigation (2)

Re: dropdb weirdness

From: Steve Grey <stevegrey78(at)gmail(dot)com>
To: Geoffrey <lists(at)serioustechnology(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, adrian(dot)klaver(at)gmail(dot)com, pgsql-general(at)postgresql(dot)org
Subject: Re: dropdb weirdness
Date: 2010-06-30 17:56:06
Message-ID: AANLkTilm73YnLqSjlbNS5ZKN5NRt7iVrdRqzbqoPPBK8@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-general
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(at)serioustechnology(dot)com> wrote:

> Tom Lane wrote:
>
>> Adrian Klaver <adrian(dot)klaver(at)gmail(dot)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(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>

In response to

pgsql-general by date

Next:From: Sam MasonDate: 2010-06-30 17:58:29
Subject: Re: Filtering by tags
Previous:From: Kelly BurkhartDate: 2010-06-30 17:34:57
Subject: Re: Backend Crash v8.4.2

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group