On Wed, Mar 11, 2009 at 5:57 PM, Glen Parker <glenebob@nwlink.com> wrote:
> Scott Marlowe wrote:
>
>> pg_dump is a perfectly acceptable backup tool, as is PITR. They have
>> different ways of operating based on what you need. Trying to make
>> PITR act more like pg_dump seems kind of silly to me.
>
> pg_dump is not acceptable to us because of the potential to lose many hours
> of valuable data.
That's why we use pg_dump and slony. We lose no data without a giant
hosting center fire.
> Why would pg_dump even be relevant to this discussion?
Because it's one method of backing up a database?
> PITR offers a benefit that pg_dump does not, a benefit that we, and
> countless other organizations, obviously find useful.
And this benefit is? Continuous backup I assume. Something other
forms of replication can do, and which pg_dump then becomes a useful
backup tool.
> Suggesting that a
> person who's been managing PG in a commercial setting since version 6.4
> should just use pg_dump as an alternative to PITR is, well, rather
> insulting.
Darn, I've only been around since 6.5.2, and have about four years on
an airline reservation system. I guess my opinions just don't count.
How could I possibly understand your advanced thought processes.
> That's two people now who have called the idea "silly" without even a hint
> of a supporting argument. Why would it be "silly" to improve the
> performance of a highly valuable tool set without compromising its utility?
Because it's the size of the WAL files that kills most people, and not
putting the index updates into WAL files would be a hack I wouldn't
trust, and having them on the otherside but not adding them is just
wasting space? Cause maybe, you didn't explain everything as clearly
as you could, and I made assumptions based on your incomplete
description?
