On 9/1/2004 10:29 AM, Joe Conway wrote:
Jeff wrote:
On Aug 31, 2004, at 6:30 PM, Josh Berkus wrote:Huh? You can replicate onto the same server. Kicks your performance in
the teeth but it works fine. Heck, I did it on my laptop as a demo.
Doesn't work If you have say, a 100GB db and only 50GB free space.
Not nearly enough to duplicate. But plenty of breathing room for normal operation.
Various db's support in place upgrades. and I'm thankful I tried Informix's out on a test db first because it simply scribbled over all the data instead of upgrading. Support told me that can happen sometimes. COOL HUH?
I think that's an incredibly important point, i.e., even if you want to do an "in place" upgrade, you ought to be testing it out first on a *full* copy of your production database. IMHO, anything less than a full test is playing fast-and-loose with your data. This in turn implies that you need enough space for a full replica anyway, so why not use slony?
Which is another point I was about to ask. How do these people, running those huge and horribly important databases, ever test a single application change? Or any schema changes for that matter. Do they really type "psql -c 'alter table ...' proddb" and believe they are professional users because they know what they are doing?
And don't tell me "we have a backup, so we could ...". That would mean that you can afford the downtime in the first place.
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 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
