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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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
>
From | Date | Subject | |
---|---|---|---|
Next Message | Sam Mason | 2010-06-30 17:58:29 | Re: Filtering by tags |
Previous Message | Kelly Burkhart | 2010-06-30 17:34:57 | Re: Backend Crash v8.4.2 |