On Montag 30 März 2009 Kevin Grittner wrote: > I don't want anything to attempt to process a WAL file while it is in > the process of being copied. By copying to a separate directory on > the same mount point and moving it, once complete, to the location > where other software is looking for WAL files, we avoid that problem. Hm. So process A copies the WAL to dir1, then moves dir1/WAL to somewhere else. But if process B processes WAL, it still does after the cp. It is no problem if B reads, A can copy without a problem, even without the cp before mv. And if B writes to WAL, you have other problems. And if A deletes WAL, B can still process it as long as it keeps the file open. So at least for Linux/Unix systems, I don't understand the benefits of cp before mv. > PostgreSQL version has nothing to do with it. PostgreSQL segments a > table into 1GB files. Our largest tables are are either "insert > only" or rarely have updates or deletes OK, that's the reason. Our db's have lots of updates/deletes everywhere, that's why I didn't think about it. > Basically, the hard links will be used to conserve disk space; rsync > will be used to conserve network bandwidth. Yes, that can make sense if the 1GB parts don't change a lot. Good idea for your scenario :-) mfg zmi -- // Michael Monnerie, Ing.BSc ----- http://it-management.at // Tel: 0660 / 415 65 31 .network.your.ideas. // PGP Key: "curl -s http://zmi.at/zmi.asc | gpg --import" // Fingerprint: AC19 F9D5 36ED CD8A EF38 500E CE14 91F7 1C12 09B4 // Keyserver: wwwkeys.eu.pgp.net Key-ID: 1C1209B4
Attachment:
signature.asc
Description: This is a digitally signed message part.
