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.dumpThis 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. # #================================================== [EMAIL PROTECTED] #
---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives?
http://archives.postgresql.org
