> We have noticed this line in our server log:
>
> Redo record at (5, 4209179252); Undo record at (0, 0); Shutdown TRUE
>
> That second number seems awfully high; should this give us cause for
> concern?
You'll see (6, ) soon.
Vadim
---(end of broadcast)---
> > We have noticed this line in our server log:
> > Redo record at (5, 4209179252); Undo record at (0, 0); Shutdown TRUE
>
> > That second number seems awfully high; should this give us cause for
> > concern?
>
> Looks fishy to me too --- the offset shouldn't exceed 24 bits AFAIR.
> Vadim, what
> In 7.1.3 and 7.2, there are only 2-3 WAL files kept because
> there is no need to keep them after a checkpoint. Is there
> any need to have these WAL config paramaters anymore?
I missed what's you propose to remove.
Vadim
---(end of broadcast)--
> > > In 7.1.3 and 7.2, there are only 2-3 WAL files kept because
> > > there is no need to keep them after a checkpoint. Is there
> > > any need to have these WAL config paramaters anymore?
> >
> > I missed what's you propose to remove.
>
> I am not proposing to remove anything. I just want to
> i just upgraded my database system from 7.0.3 to 7.1 ... i
> did a dumpall and psql -f dump.sql to the new db. the data
> is in place correctly and its running fine. but as soon as
> i put the connections back on to the db the load raised to
> 6. prior to the upgrade the system load was an 0.3 .
> >> Warning: PostgreSQL query failed: FATAL 1: my bits moved
> >> right off the end of the world! Recreate index
> >> pg_attribute_relid_attnum_index.
>
> This is an internal "can't happen" failure condition,
> presumably arising from some weird corner-case bug in btree
> index manipulation. W
> Hmm ... so you think the people who have complained of this are all
> working with databases that have suffered previous crash corruption?
> I doubt it. There's too much consistency to the reports: in
> particular, it's generally triggered by creation of lots of large
> objects, and it's always
> when i do a vacuum, i see in debug message that my datas are
> there (1800 tuples etc...)
>
> when i do a select..0 rows !
Try to reindex database.
Vadim
> I tried, but nothing has changed !
>
> The strangest is I have a database which was not accessed
> sinc several days and even this one does not function
>
> in pg_class, I see for exemple that one on my table has
> ntuples=1800 but I can't access it...
Oh, so you're able to select from
> I've searched the documentation and the mailing lists archive but I'm
> unable to find info on setting checkpoints and performing roll-forward
> operations with the transaction log. I'd appreciate it if
> someone could point me to the right docs.
WAL stuff is not documented yet.
Anyway you sho
> The 7.1 Release notes include the statement re WAL below.
>
> "Write-ahead Log (WAL)
> To maintain database consistency in case of an operating system crash,
> previous releases of PostgreSQL have forced all data modifications to
> disk before each transaction commit. With WAL, only one log fil
11 matches
Mail list logo
