Please excuse the delay in replying.. >Tom Lane > Joe Conway <[EMAIL PROTECTED]> writes: > > Simon Riggs wrote: > >> O... and other dbms will freeze when this situation is hit, rather > >> than continue and drop archive logs.] > > > Been there, done that, don't see how it's any better. I hesitate to be > > real specific here, but let's just say the end result was restore from > > backup :-(
Myself also. I accept your experience and insight, I apologise if my own seemed overblown. My take on that is that if you're in a situation that has a high probability of going bad, the last thing you would want is to drop xlogs. Same technical experience, different viewpoint on what to learn from it. > It's hard for me to imagine a situation in which killing the database > would be considered a more attractive option than dropping old log > data. You may or may not ever need the old log data, but you darn well > do need a functioning database. (If you don't, you wouldn't be going to > all this work.) The main point here for me is that the choice of keeping archived (not old) log files against keeping the database up isn't actually mine to make; that choice belongs to the owner of the database, not me as developer or administrator, consultant or whatever. Although I admit I did not at first comprehend that such a view was possible, I did flex to allow yours and Joe's perspective when that was voiced. The point is one of risk: does the owner wish to risk the possibility that a transaction may be lost in order to keep the database up? The possibility of lost rows must be balanced against the probably higher possibility of being unable to write new data. But which is worse? Who can say? In some environments where I have worked, (again forgive any seeming personal arrogance or posturing), such as banks or finance generally, it has been desirable to stop the system rather than risk losing even a single row. In other situations, lost rows must be balanced against the money lost through downtime. Guess it depends whether you've got a contract for uptime or for data integrity?? ;) > I repeat: code that pushes > logs into a secondary area is not ours to write. We should concentrate > on providing an API that lets users write it. Agreed. > We have only limited > manpower for this project and we need to spend it on getting the core > functionality done right, not on inventing frammishes. Love that word "frammish"...seriously, I understand and agree. My understanding is that existing logic will cause a PANIC if the xlog directory cannot be written to. Helping the database stay up by dropping logs would require extra code... This was an edge case anyhow... Best Regards, Simon Riggs ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
