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 location. At some predetermined interval, push WAL log
segments no longer needed to the
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
Bruce Momjian
Simon Riggs wrote:
User-selectable behaviour? OK. That's how we deal with fsync; I can
relate to that. That hadn't been part of my thinking because of the
importance I'd attached to the log files themselves, but I can go
with
that, if that's what was meant.
So, if we had
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
Simon Riggs wrote:
Bruce Momjian
Simon Riggs wrote:
User-selectable behaviour? OK. That's how we deal with fsync; I can
relate to that. That hadn't been part of my thinking because of the
importance I'd attached to the log files themselves, but I can go
with
that, if that's what
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
Simon Riggs wrote:
User-selectable behaviour? OK. That's how we deal with fsync; I can
relate to that. That hadn't been part of my thinking because of the
importance I'd attached to the log files themselves, but I can go with
that, if that's what was meant.
So, if we had a parameter called
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 how it's any better. I hesitate to be
real
Tom Lane wrote:
I think also that Simon completely misunderstood my intent in saying
that this could be user-scriptable policy. By that I meant that the
*user* could write the code to behave whichever way he liked. Not that
we were going to go into a mad rush of feature invention and try to
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
Tom Lane wrote:
One of the things that bothers me about the present PITR design is that
it presumes that individual WAL log segments can be kept until the
external archiver process feels like writing them somewhere. If there's
no guarantee that that happens within X amount of time, then you can't
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
14 matches
Mail list logo
