Please excuse the delay in replying..
>Tom Lane
> Joe Conway <mail@joeconway.com> 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