> > I see that seek+write was changed to write-s in XLogFileInit
> > (that was induced by subj, right?), but what about problem
> > itself?
>
> > BTW, were performance tests run after seek+write --> write-s
> > change?
>
> That change was for safety, not for performance. It might be a
> perform
> > Was the following bug already fixed ?
>
> Dunno. I've changed the WAL ReadRecord code so that it fails soft (no
> Asserts or elog(STOP)s) for all failure cases, so the particular crash
> mode exhibited here should be gone. But I'm not sure why the code
> appears to be trying to open the wro
"Vadim Mikheev" <[EMAIL PROTECTED]> writes:
> I see that seek+write was changed to write-s in XLogFileInit
> (that was induced by subj, right?), but what about problem
> itself?
> BTW, were performance tests run after seek+write --> write-s
> change?
That change was for safety, not for performan
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> Was the following bug already fixed ?
Dunno. I've changed the WAL ReadRecord code so that it fails soft (no
Asserts or elog(STOP)s) for all failure cases, so the particular crash
mode exhibited here should be gone. But I'm not sure why the code
appear
> Was the following bug already fixed ?
I was going to ask same Q.
I see that seek+write was changed to write-s in XLogFileInit
(that was induced by subj, right?), but what about problem
itself?
> > DEBUG: redo starts at (0, 21075520)
> > The Data Base System is starting up
> > DEBUG: open(log
Was the following bug already fixed ?
Regards,
Hiroshi Inoue
Tom Lane wrote:
>
> With current sources:
>
> DEBUG: copy: line 629980, XLogWrite: new log file created - try to increase
>WAL_FILES
> DEBUG: copy: line 694890, XLogWrite: new log file created - try to increase
>WAL_FILES
> FATAL
>> Regardless of whether this particular behavior is fixable,
>> this brings up something that I think we *must* do before
>> 7.1 release: create a utility that blows away a corrupted
>> logfile to allow the system to restart with whatever is in
>> the datafiles. Otherwise, there is no recovery t
[ Charset ISO-8859-1 unsupported, converting... ]
>
> > Regardless of whether this particular behavior is fixable, this brings
> > up something that I think we *must* do before 7.1 release: create a
> > utility that blows away a corrupted logfile to allow the system to
> > restart with whatever i
> Regardless of whether this particular behavior is fixable, this brings
> up something that I think we *must* do before 7.1 release: create a
> utility that blows away a corrupted logfile to allow the system to
> restart with whatever is in the datafiles. Otherwise, there is no
> recovery techn
Tom Lane wrote:
>
> With current sources:
>
> DEBUG: copy: line 629980, XLogWrite: new log file created - try to increase
>WAL_FILES
> DEBUG: copy: line 694890, XLogWrite: new log file created - try to increase
>WAL_FILES
> FATAL 2: copy: line 759383, ZeroFill(logfile 0 seg 13) failed: No sp
With current sources:
DEBUG: copy: line 629980, XLogWrite: new log file created - try to increase WAL_FILES
DEBUG: copy: line 694890, XLogWrite: new log file created - try to increase WAL_FILES
FATAL 2: copy: line 759383, ZeroFill(logfile 0 seg 13) failed: No space left on device
Server proces
11 matches
Mail list logo
