Simon Riggs [EMAIL PROTECTED] writes:
Strict behaviour is fairly straightforward, you just PANIC!
There is another mode possible as well. Oracle for example neither panics nor
continues, it just freezes. It keeps retrying the transaction until it finds
it has space.
The sysadmin or dba just
Joe Conway [mailto:[EMAIL PROTECTED]
Simon Riggs wrote:
Tom Lane [mailto:[EMAIL PROTECTED] That should be user-scriptable
policy, in my worldview.
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
Tom Lane [mailto:[EMAIL PROTECTED]
Joe Conway [EMAIL PROTECTED] writes:
Tom Lane wrote:
Joe Conway [EMAIL PROTECTED] writes:
Maybe specify an archive location (that of course could be on a
separate
partition) that the external archiver should check in addition to
the
normal WAL
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
Tom Lane [mailto:[EMAIL PROTECTED]
Simon Riggs [EMAIL PROTECTED] writes:
You're absolutely right about the not-knowing when you're out of
space
issue. However, if the xlog has been written then it is not
desirable,
but at least acceptable that the checkpoint/bgwriter cannot complete
on
an
Simon Riggs [EMAIL PROTECTED] writes:
Tom Lane wrote:
Right. This is in fact not a fatal situation, as long as you don't
run out of preallocated WAL space.
Clearly running out of pre-allocated WAL space is likely to be the next
issue. Running out of space in the first place is likely to
Joe Conway [EMAIL PROTECTED] writes:
Tom Lane wrote:
facing the possibility of an out-of-WAL-space panic. I suspect that we
cannot really do anything about that, but it's annoying. Any bright
ideas out there?
Maybe specify an archive location (that of course could be on a separate
