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 location. At some predetermined
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
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, i
>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 t
>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.
> >
> >
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 hesitat
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
sup
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 specifi
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 ca
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 resul
>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
>
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
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
"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 l
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 comple
16 matches
Mail list logo
