On Aug 1, 2013, at 11:27, Stephen Brearley <mail@xxxxxxxxxxxxxxxxxxxx> wrote: > Hi Alban > > Think we are making progress.. > > I'll need to do some research to understand how to find the event log, but > to answer your other points: > > 1) Glad to see you think the database started up correctly. I also noted > this problem about adminpack, and spent ages trying to find out what it was > and why it was not now installing correctly, but so far I have drawn a > blank. It interrupted the installation with a pop-up error message, although > it did allow me to continue. That was why I thought it was a program bug, > and tried to report it! That does indeed seem like an issue with the installer. I suspect the EnterpriseDB people (who create the Windows package) are following this thread and will follow up on this, but perhaps it wouldn't hurt to contact them directly about this ;) > 2) Yes, I did stop the Postgres before moving my data. I moved my data to > \data_old, then did the uninstall, re-installed it, stopped the program and > moved the data from \data_old back to \data and re-started Postgres. I also > checked that my registry settings for Postgres were pointing to the correct > data folder on the D: drive (which is why the install may know about it), > which is just a separate partition on my PC. Before I had any of these > problems, Postgres was able to successfully read and write to this location. > I was using Navicat to create a few basic tables, and did manage to log into > pgAdmin. I can't see any flaw in that. Out of curiosity, is that a separate partition on the same disk? If so, what benefit do you expect from that? If you were talking about a separate disk (one that doesn't contain the Windows page-file, for example) then it makes sense to do so, but on the same disk I don't really see the benefit… Easier with backups, perhaps? > 3) The log file I have attached is from the last re-install. Every time I > have uninstalled and re-installed since my first successful attempt has > produced the same (unsuccessful) result, so I think any of these logs will > show the same issues. Probably, yes. > 4) The Postgres help files seem to suggest that during an uninstall, the > /data folder will not be deleted, which seems quite sensible, as you say! > Only thing is, the system requires it to be empty during an install, as folk > are expected to either install Postgres for the first time, or perform an > upgrade which uses a different 9.x folder, and not have to reinstall the > same version. This is why I have to shift my data out of the way to > /data_old and shift it back. Assuming I can do this without using > dump/restore (another question). Yes, with the same major version of the database (PG 9.2 in your case), you can. I think the issue at hand here is that the installer doesn't know whether any pre-existing data is for the same major version or not and therefore cannot assume it is safe to keep it around. Having to re-install the same version is a bit uncommon, I suppose, but you'd probably run into the same issue if you were to perform a minor version upgrade (say 9.2.4 to 9.2.5)? > 5) I typed netstat -an, and found port 5432 was shown as: > Local Address: [::]:5432, Foreign Address: [::]:0, State: LISTENING > > I don't think I chose this port, I think the install defaulted to it. I > don't know if this is the right one I should choose. According to Wikipedia, > this is the default port for Postgres on TCP/UDP, although my system does > not seem to be listening on UDP, but I think just listening on TCP is > probably fine. Yes, that's the default port and it shows that the database is indeed running and listening. So far so good! > 6) This question about connecting -I think- could be what the problem is. To > connect, I start pgAdmin and double-click on Server > groups|Servers|myLocalHost (localhost:5432) which has a red 'X' on it > (doesn't look good) to which I get a popup 'Error connecting to the server: > FATAL: password authentication failed for user "SDB"'. You mention the > pg_hba.conf file -but since I am asked to enter a new password during > installation, this is reset every time I try to do a reinstall? I am > thinking that this is not occurring, and I have entered to many wrong > passwords. For security, it would make sense that you can't reset it just by > performing a reinstall. Could you elaborate on how to get back in if I have > locked myself out please, as I think this could..be it? Well, pg_hba.conf (which location is mentioned by Raymond further down this thread) doesn't contain your passwords but is the configuration file to specify what authentication methods (if any) are required to connect from what hosts. Apparently that file says to use password authentication for the host you're connecting from. If you're on the same machine as the database is (I suspect you are), that would be "localhost". That's another file that the installer does not touch if it exists, for similar reasons as why it doesn't touch your data; the contents of that file can be quite elaborate in larger installations. Another thing that I wonder about; can you connect to the database using the standard "postgres" (without quotes) user? That's the default admin user. It wouldn't surprise me if there's simply no database account for user "SDB"! If you can connect using the postgres user, you can then also create a database account for your SDB user. P.S. In this mailing list it is not customary to top-post. You're on a Micrososft OS, possibly using the abomination of a mail client called Outlook, so you can possibly not help it, but if you can, please reply in context so that we don't have to reverse-read your messages. > -----Original Message----- > From: Alban Hertroys [mailto:haramrae@xxxxxxxxx] > Sent: 31 July 2013 14:16 > To: Stephen Brearley > Cc: pgsql-general@xxxxxxxxxxxxxx; 'Adrian Klaver' > Subject: Re: Postgres 9.2.4 for Windows (Vista) Dell Vostro 400, > re-installation failure PLEASE CAN SOMEONE HELP!! > > On Jul 31, 2013, at 14:07, "Stephen Brearley" <mail@xxxxxxxxxxxxxxxxxxxx> > wrote: > >> Hi Alban >> >> Much thanks for getting back to me! >> >> The event file gets written to (as attached): >> C:\Users\SDB\AppData\Local\Temp > > That's the installation log, not the postgres log. > I suspect the postgres log is either in the Windows Event Log (available > from the Control Panel, perhaps under Administrative Tools or something > similar) or in a file somewhere in the Postgres installation directory, most > likely in a directory named log. I don't know how EnterpriseDB sets things > up though, certainly not in Windows. > > Nevertheless, from the installation log it can be seen that initdb was run > and that after that the database started up successfully. > > It also shows that some module named "adminpack" failed to install. I have > no idea what that is though, I don't have it on my UNIX system. > See: > > Script output: > Installing the adminpack module in the postgres database... > Executing 'C:\Users\SDB\AppData\Local\Temp\rad5E7BA.bat'... > Couldn't find the output file... > Failed to install the 'adminpack' module in the 'postgres' database > loadmodules.vbs ran to completion > > Script stderr: > Program ended with an error exit code > > Error running cscript //NoLogo "C:\Program > Files\PostgreSQL\9.2\installer\server\loadmodules.vbs" "postgres" "****" > "C:\Program Files\PostgreSQL\9.2" > "D:\_SDB\Database\RDBMS\PostgreSQL\9.2\data" 5432 : Program ended with an > error exit code > > So, whatever causes your issue is most likely due to something that happened > after the install. > >> I copied the contents of the /data directory to the D: drive, then >> changed the folder reference in the Registry. However, after this I >> was able to > > Did you first stop the database? If not, chances are you didn't get a > consistent copy, because the database was working on those files while you > were copying them. > Oh, and I assume your D: drive isn't some kind of network drive or > something, but an actual disk with NTFS on it? > >> create tables in Navicat without any problems, until I tried to use >> pgAdmin when it required my password, which I had forgotten. Then I >> tried to reinstall, and started having these problems.. > > So all the above is from before you uninstalled/reinstalled? Or is that log > file you attached from the reinstall? > In that case, it seems to have known about your data-directory on D: during > the install, looking at this snippet: > > Loading additional SQL modules... > Executing cscript //NoLogo "C:\Program > Files\PostgreSQL\9.2\installer\server\loadmodules.vbs" "postgres" "****" > "C:\Program Files\PostgreSQL\9.2" > "D:\_SDB\Database\RDBMS\PostgreSQL\9.2\data" 5432 Script exit code: 2 > > It exits with code 2, which indicates an error. Perhaps the logs (see > earlier) say why. > >> I'm being recommended to try running pg_dump by Thomas Kellerer, then >> remove all my data folders and a reinstall. I get the feeling it is >> not moving my data to the D: drive that has caused the problem, but >> that the Uninstall has not cleaned this out correctly, as I moved my >> data to D:/../data_old to enable Postgres to reinstall and used the >> installation Wizard to point to my data location, but still get >> installation errors and a connection problem, despite using the 'correct' > password. > > I doubt that the uninstaller would remove your data directory, because then > you would lose your data. You don't want that, it's generally better to > leave decisions like that up to the administrator (you). That data is more > often than not quite valuable ;) > >> When I start pgAdmin, TaskManager shows that Postgres is running, -so >> I don't think I have an unrecoverable database snapshot? > > That Postgres appears to be running is encouraging. > > Something worth verifying; open a command prompt and type netstat -an and > look whether the port you configured Postgres to run on is being listened > on. > > If it is, then your issue is just a connection issue. Perhaps you could > elaborate on what you're doing to connect and what error you receive? > > It's possible that you locked yourself out through the pg_hba.conf file or > that you need to reset the password for the postgres user. But we don't know > that yet... > > >> -----Original Message----- >> From: Alban Hertroys [mailto:haramrae@xxxxxxxxx] >> Sent: 31 July 2013 11:48 >> To: Stephen Brearley >> Cc: 'Adrian Klaver'; pgsql-general@xxxxxxxxxxxxxx >> Subject: Re: Postgres 9.2.4 for Windows (Vista) Dell Vostro >> 400, re-installation failure PLEASE CAN SOMEONE HELP!! >> >> On Jul 31, 2013, at 12:07, "Stephen Brearley" >> <mail@xxxxxxxxxxxxxxxxxxxx> >> wrote: >> >>> Both the install and uninstall should work flawlessly. The only thing >>> I can see is that I have installed the program once before, and I >>> have put my data on my d: drive to separate it from the program in >>> case of software problems, but I got Postgresql to correctly find my data > before.. >> >> >> If Postgres is having any issues starting up, details should be in the >> log file. I don't know where that file gets written on a Windows >> system though, perhaps it ends up in the Windows Event log? >> >> What procedure did you follow to move your data to the D-drive? That >> seems a likely cause of trouble, especially if the database was >> running while you did that - you may be looking at an unrecoverable >> database snapshot if you didn't take precautions, in which case the >> database would refuse to start up. >> >> Alban Hertroys >> -- >> If you can't see the forest for the trees, cut the trees and you'll >> find there is no forest. >> >> <install-postgresql.log> > > Alban Hertroys > -- > If you can't see the forest for the trees, cut the trees and you'll find > there is no forest. > > Alban Hertroys -- If you can't see the forest for the trees, cut the trees and you'll find there is no forest. -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
