another windows admin running all his service
under the administrator context.
I needed the PostgreSQL setup to prove to a customer
that a working setup could be made using PGSQL. It lived
on my system for a couple of days in total, so cooking
up a perfectly secure system was hardly worth it, in fact
it was a major waste of my time.
The machine in question has a firewall, so external
connections to the service would never occur.
PostgreSQL telling me how to run my system security-wise
is infinitely annoying. Feels like being locked in a
cage, which is always an insulting way to treat a user.
I just tried the same approach with another popular
open source database. It indeed also refuses to start,
but the user isn't locked out. It kindly says "you
probably shouldn't be doing this, but if you really want
to, you can run as root with --user=root".
Anyway, I just enabled the guest account on the machine
in question and started a command prompt under those
credentials. Things wouldn't work unless the guest
account was allowed sign-on privileges (?), so it has
those now. I've actually forgotten to disable them again,
so argueably being forced by PostgreSQL to run as another
user has actually caused *worse* security on this machine
than would otherwise be the case :-).
Oh well, enough ranting about that already.
Everything worked very smoothly once I had wasted a couple
of hours getting it to start.
Thanks for all the feedback regarding "pg_ctl register"
etc. and thanks for the discussion!
The point I was trying to make is that recovery is never
a cookbook process --- it's never twice the same problem.
(If it were, we could and should be doing something about
the underlying problem.) This makes it difficult to
provide either polished tools or polished documentation.
I've seen a ton of wedged databases. Missing a tuplet here
or there after recovery because the process applied by the
tool used is imperfect has never been a problem for any
company I've been at. Minimal time to recover has always
been far more critical. And also the money paid for the
actual recovery in terms of paychecks matter a lot.
Simply put, a tool with just a single button named "recover
all the data that you can" is by far the best solution in so
many cases. Minimal fuzz, minimal downtime, minimal money
spent on recovery. And perhaps there's even a good chance that
any missing data could be entered back into the system manually.
The only time I've ever heard of experts being brought in
to fix a database problem was when IBM's DB2 system crashed for
a major bank in Scandinavia. But that's banking data, so that's
an entirely different story from everyday use by any other kind
of corporation. It's .01% of the market, it's really not
that interesting if you ask me.
Ok, long rant short, convincing any company to use a database
system is much easier when that particular system has a one-click
recovery application. Same reason why NTFS and FAT32 are
filesystems that people like to keep their data on - they know
that when things do go wrong, they can launch Tiramisu or
Easy Recovery Pro or what not and just tell it "recover as much
as you can onto this other disk". People sleep safer if they
know that there's a backup plan, in particular one that doesn't
require two months of downtime while your DBA is learning the
innards of the database system file structure, posting to a
mailing list *hoping* that there's someone that can and wants
to talk to him (while he's at his most stressed) who has the
required expertise, etc.
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
