Re: [ADMIN] [HACKERS] Point in Time Recovery

2004-07-22 Thread Mark Kirkwood
I have tested the "cold" backup - and retested my previous scenarios using "hot" backup (just to be sure) . They all work AFAICS! cheers Mark Simon Riggs wrote: On Thu, 2004-07-22 at 21:19, Tom Lane wrote: Mark Kirkwood <[EMAIL PROTECTED]> writes: 2) Is is pos

Re: [ADMIN] [HACKERS] Point in Time Recovery

2004-07-22 Thread Mark Kirkwood
Excellent - Just updated and it is all good! This change makes the whole "how do I do my backup" business nice and basic - which the right way IMHO. regards Mark Tom Lane wrote: Mark Kirkwood <[EMAIL PROTECTED]> writes: 2) Is is possible to make the recovery kick in even t

Re: [ADMIN] [HACKERS] Point in Time Recovery

2004-07-21 Thread Mark Kirkwood
Well that is interesting :_) Here is what I am doing on the removal front (I am keeping pg_xlog *now*): $ cd $PGDATA $ pg_ctl stop $ ls|grep -v pg_xlog|xargs rm -rf The contents of the archive directory just before recovery starts: $ ls -l $PGDATA/../7.5-archive total 49212 -rw---1 postgres

Re: [ADMIN] [HACKERS] Point in Time Recovery

2004-07-21 Thread Mark Kirkwood
Here is one for the 'idiot proof' category: 1) initdb and set archive_command 2) shutdown 3) do a backup 4) startup and run some transactions 5) shutdown and remove PGDATA 6) restore backup 7) startup Obviously this does not work as the backup is performed with the database shutdown. This got me

Re: [ADMIN] [HACKERS] Point in Time Recovery

2004-07-14 Thread Mark Kirkwood
I noticed that compiling with 5_1 patch applied fails due to XLOG_archive_dir being removed from xlog.c , but src/backend/commands/tablecmds.c still uses it. I did the following to tablecmds.c : 5408c5408 < extern char XLOG_archive_dir[]; --- > extern char *XLogArchiv

Re: [ADMIN] [PERFORM] Quad processor options - summary

2004-05-14 Thread Mark Kirkwood
I would recommend trying out several stripe sizes, and making your own measurements. A while ago I was involved in building a data warehouse system (Oracle, DB2) and after several file and db benchmark exercises we used 256K stripes, as these gave the best overall performance results for both

Re: [ADMIN] [PERFORM] Benchmarking postgres on Solaris/Linux

2004-03-25 Thread Mark Kirkwood
The hardware platform to deploy onto may well influence your choice : Intel is usually the most cost effective , which means using Linux makes sense in that case (anybody measured Pg performance on Solaris/Intel?). If however, you are going to run a very "big in some sense" database, then 6

Re: [ADMIN] [PERFORM] Benchmarking postgres on Solaris/Linux

2004-03-25 Thread Mark Kirkwood
Josh Berkus wrote: Mark, It might be worth considering Apple if you want a 64-bit chip that has a clock speed comparable to Intel's - the Xserv is similarly priced to Sun V210 (both dual cpu 1U's). Personally I'd stay *far* away from the XServs until Apple learns to build some real ser