Re: Re: Postgres 9.2.4 for Windows (Vista) Dell Vostro 400, re-installation failure PLEASE CAN SOMEONE HELP!! (nearly fixed)

On Fri, Aug 2, 2013 at 10:18 AM, Adrian Klaver <adrian(dot)klaver(at)gmail(dot)com>wrote:

> You can't do that and have it work. \base is just part of the puzzle, you
> need the complete \data directory for Postgres to work.
>
> The problem(as stated before) is you have two distinct installations of
> the Postgres data directory, one on D:\ and one on C:\. In Postgres
> parlance the \data directory in each of those locations represents a
> database cluster. The procedure you described above for the successful
> install set up Postgres to run off the C:\ cluster. All the stuff you are
> doing on D:\ will be of no use until you point Postgres at the cluster on
> D:\(I don't think changing the registry entry counts). Unfortunately my
> lack of knowledge regarding Postgres on Windows means I will be of no help
> there. Someone else will need to fill in the procedure.
>
> I have to ask again, how important is the old data and how much is there?
>
> Would it be easier to just reenter it in the new cluster?
>

If by "modifying the registry," Mr. Brearley means following the procedure
described here on the PostgreSQl
Wiki<http://wiki.postgresql.org/wiki/Change_the_default_PGDATA_directory_on_Windows>,
then that actually will change the data directory. That procedure actually
modifies the Windows service command line (stored in the registry), and it
changes the -D argument. (Yes, that appears to have been written against
8.3RC2, but I checked, and it is still applicable to 9.2 if names are
changed appropriately.)

Instead of changing the service, it might be more effective to just stop
the service and manually start PostgreSQL from the command line until the
data can be retrieved. That would allow for somewhat more consistent usage
with other operating systems, making it simpler to help. If he can get
something to connect to that data directory, that would allow him to at
least dump the data so it could be imported into a new, empty cluster.

My big concern as I've been reading this thread is whether users are
cluster specific or installation specific. If they're cluster specific,
he'll need to know credentials for his original cluster anyway to get the
data, unless he can do some kind of password reset.