Largest Provider of Commercial Smalltalk
Cincom is one of the largest commercial providers of Smalltalk, with twice as many customers and partners as other commercial providers.

Tom Nies

Get Started

Crash! – Experience Report

Posted on in Categories Smalltalk

Many Cincom Smalltalk developers use Store as a capable source code repository.  I do, and I depend on it.  I use PostgreSQL as the database for my Store repository. It is a popular and capable solution that many Smalltalk developers use.

Recently I had the misfortune of having trouble with my PC.  It has been rock solid for years, but it seemed to have an issue booting one morning.  I eventually got it booted and ran some Microsoft “fix-it” tools to identify and fix potential issues.  It ran fine the rest of the day, and I thought the issues were behind me.  The next morning it refused to boot, and no amount of retrying or tactics to get it to boot in safe mode or anything else worked.

Luckily, I did have a second Windows 7 machine I had recently built.  I started to install and configure my email and other needed software to start using it as my mainstay computer.

Now here’s the big question that was looming:  How do I move or recover my Store database that went down with the old machine?

I make and keep general backups on a 2Tb backup drive, so most of my documents were recoverable.  The first thing I did was pull the C: drive out of the old machine and mount it on a USB interface to see if I could access its contents; I could! (phew!)

I then tried to find instructions on how to recover a Postgres installation from the raw files;  there wasn’t much available.  The preferred method is to use pgDump and pgRestore to back up and restore a Postgresql installation.  I had not reached that level of sophistication (but I will look at that now! ).

I was ultimately successful without too much difficulty, and want to share what I did in case you find yourself in the same situation.  Note that my installation is Postgres version 8.4.x.

What I did:

  • I installed Postgres on my new machine.  I wanted the same version (or one very close to it) and found that version 8.4.17 was available and still supported.
  • I recovered the PostgresQL/8.4 directory from the old machine and made a copy on my new machine.
  • I stopped the database (PG installs a start and stop command in the installation).
  • I renamed the PostgresQL/8.4/data directory in case I wanted to recover the initial installation.
  • I copied the recovered data directory into PostgresQL/8.4.
  • I ran pg_resetxlog—one of the few recommendations I found for doing what I was trying to accomplish.
  • I tried to start the db server, but it didn’t work.
  • I rebooted the machine and tried to start the PostgreSQL server again; still no luck.
  • The start complained about the lock file and suggested deleting  I deleted it.
  • I tried restarting.  It complained that it could not create the lock file.
  • I found instructions on opening a command dialog in order to execute as the Postgres user.
    • Type ”run” into the entry field that’s shown after pressing the windows “start” button.  Type in and run:   runas /user:postgres “cmd”.
    • I again tried restarting from cmd dialog; still no luck.
    • I found some information suggesting that permissions could be an issue.  It only gave Linux instructions. I went to the data folder, right clicked, selected properties and went to the security tab.  I compared this with the security access for the renamed data dir that was installed with the new installation.  It had Postgres as a user, with full permissions.  I added this user (Postgres) and gave it full access.
    • I started the server … it worked!
    • I connected from an image to my store repository and confirmed the contents; job complete!