Oli Sennhauser wrote:
>>>> People might be more interested in debating this topic with you if we
>>>> hadn't discussed it at length just a couple months back. There wasn't
>>>> consensus then that we had to offer an escape hatch, and you've not
>>>> offered any argument that wasn't made before.
>>>
>>>
>>> I'm simply presenting a problem for which I currently do not see any
>>> solution
>>> (it's very important for us to be able to restore db within a
>>> reasonable amount
>>> of time). If there's no solution and none is planned, then we cannot
>>> use pgsql,
>>> can we?
>>
>>
>> You're simply presenting a problem that isn't there in the first
>> place. If you really feel the need to shoot yourself in the foot, use
>> separate schema and data dumps and do the latter with "-X
>> disable-triggers".
>>
>> And now will you please put it to rest?
>
> If this is not a prio 1 problem, what are then the prio one problems???
Did you read my mail or only that last sentence?
> You are a developer, right? Did you ever manage a big database in
> production? What shoul I tell to my customers when they want to have a
> not that big database (100 GB) in PostgreSQL: "I am sorry, but we are
> not able to do performant backups, I recommend you to choos ORACLE
> instead???". Is it this we/you recommend?
Among many other things I am a developer too, and I have managed
customer databases up to 1.2 TB. But I wonder what you are.
You should tell your customers that they have to dump their databases as
pg_dump -d swisscheese >swisscheese.schema.dump pg_dump -a -X disable-triggers swisscheese
>swisscheese.data.dump
This is what I recommended in my previous mail. Is that an unacceptable
solution for your customers or what is the problem?
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #
