SEO

> 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 majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, Dec 18, 2006 at 03:47:42AM +0100, Molle Bestefich wrote:

[...]

> 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.

I think the point which has been made here was that the recovery tool
*is already there*: i.e. all what can be done as an "one-click" recovery
is done by the system at start-up. Beyond this no cookbook exists (and
thus no way to put it under an one-click procedure).

So this one-click thing would be mainly something to cater for the
"needs" of marketing.

Regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFFjg4/Bcgs9XrR2kYRAtnSAKCCFkB+YAlvbuyhepUnR9/CeG3tsACfb8bE
lCszfmaps1PN1jLMQrc6eLo=
=/6Pa
-----END PGP SIGNATURE-----


---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

On 12/24/06, tomas@tuxteam.de <tomas@tuxteam.de> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Mon, Dec 18, 2006 at 03:47:42AM +0100, Molle Bestefich wrote:
>
> [...]
>
> > 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.
>
> I think the point which has been made here was that the recovery tool
> *is already there*: i.e. all what can be done as an "one-click" recovery
> is done by the system at start-up. Beyond this no cookbook exists (and
> thus no way to put it under an one-click procedure).
>
> So this one-click thing would be mainly something to cater for the
> "needs" of marketing.

Well start-up recovery is great and reliable. The only problem is that
it won't help if you have some obscure hardware problem, you really
have a problem. If you want to sleep well, you should know what to
do when disaster happens.

I really like the approach of XFS filesystem, which ships with fsck.xfs
which is essentially equivalent to /bin/true. They write in their white
paper that they did so, because journaling should recover from all
failures. Yet they also wrote that some time after they learned that
hardware corruption is not as unlikely as one might assume, so they
provide xfs_check an xfs_repair utilities.

I think there should be a documented way to recover from obscure
hardware failure, with even more detailed information how this could
result only from using crappy hardware... And I don't think this should
be "one click" process -- some people might miss real (software)
corruption, and this is a biggest drawback. Perhaps the disaster
recoverer should leave a detailed log which would be enough to
detect software-corruption even after the recovery [and users should
be advised to send them].

Regards,
Dawid Kuroczko

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

A long time ago, in a galaxy far, far away, qnex42@gmail.com ("Dawid Kuroczko") wrote:
> On 12/24/06, tomas@tuxteam.de <tomas@tuxteam.de> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On Mon, Dec 18, 2006 at 03:47:42AM +0100, Molle Bestefich wrote:
>>
>> [...]
>>
>> > 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.
>>
>> I think the point which has been made here was that the recovery tool
>> *is already there*: i.e. all what can be done as an "one-click" recovery
>> is done by the system at start-up. Beyond this no cookbook exists (and
>> thus no way to put it under an one-click procedure).
>>
>> So this one-click thing would be mainly something to cater for the
>> "needs" of marketing.
>
> Well start-up recovery is great and reliable. The only problem is that
> it won't help if you have some obscure hardware problem, you really
> have a problem. If you want to sleep well, you should know what to
> do when disaster happens.
>
> I really like the approach of XFS filesystem, which ships with fsck.xfs
> which is essentially equivalent to /bin/true. They write in their white
> paper that they did so, because journaling should recover from all
> failures. Yet they also wrote that some time after they learned that
> hardware corruption is not as unlikely as one might assume, so they
> provide xfs_check an xfs_repair utilities.
>
> I think there should be a documented way to recover from obscure
> hardware failure, with even more detailed information how this could
> result only from using crappy hardware... And I don't think this should
> be "one click" process -- some people might miss real (software)
> corruption, and this is a biggest drawback. Perhaps the disaster
> recoverer should leave a detailed log which would be enough to
> detect software-corruption even after the recovery [and users should
> be advised to send them].

The trouble is that it is often *impossible* to recover from the
"obscure hardware failure."

If the failure is that a bunch of vital bits have been lost or
scribbled on, there may be NO way to recover from this.

And in practice, this in fact seems to be a common form for "obscure
hardware failure" to take: those problems are, in fact, irretrievable.

There historically have been two main sorts of corruptions:

1. Hardware corruptions where the only recovery is to have some sort
of replica of the data, whether via near-hardware mechanisms (e.g. -
RAID) or more 'logical' mechanisms (e.g. - replication systems).

2. Software corruptions, where the answer is not to provide some
"recovery mechanism," but rather to FIX THE BUG that is leading to the
problem. Once the bug is fixed, there is no more corruption (of this
sort).

Neither of these is amenable to there being some mechanism such as you
describe. There are really only two possibilities:

a) The problem is one that the WAL recovery system can cope with, or

b) There has been True Data Loss, and there is NO recovery system
short of recovering from backup/replica.
--
output = ("cbbrowne" "@" "acm.org")
http://cbbrowne.com/info/slony.html
"Here I am, brain the size of a planet, and they ask me to take you
down the the bridge. Call that job satisfaction? 'Cos I don't."
-- Marvin the Paranoid Android