> > > So are whole pages stored in rollback segments or just
> > > the modified data?
> >
> > This is implementation dependent. Storing whole pages is
> > much easy to do, but obviously it's better to store just
> > modified data.
>
> I am not sure it is necessarily better. Seems to be a tradeof
> > > > You mean it is restored in session that is running the transaction ?
> >
> > Depends on what you mean with restored. It first reads the heap page,
> > sees that it needs an older version and thus reads it from the "rollback segment".
>
> So are whole pages stored in rollback segments or
> > - A simple typo in psql can currently cause a forced
> > rollback of the entire TX. UNDO should avoid this.
>
> Yes, I forgot to mention this very big advantage, but undo is
> not the only possible way to implement savepoints. Solutions
> using CommandCounter have been discussed.
This would
At 11:25 23/05/01 +0200, Zeugswetter Andreas SB wrote:
>
>> >If community will not like UNDO then I'll probably try to implement
>> >dead space collector which will read log files and so on.
>>
>> I'd vote for UNDO; in terms of usability & friendliness it's a big win.
>
>Could you please try it
> > 1. Compact log files after checkpoint (save records of uncommitted
> >transactions and remove/archive others).
>
> On the grounds that undo is not guaranteed anyway (concurrent
> heap access), why not simply forget it,
We can set flag in ItemData and register callback function in
buffer
> Correct me if I am wrong, but both cases do present a problem
> currently in 7.1. The WAL log will not remove any WAL files
> for transactions that are still open (even after a checkpoint
> occurs). Thus if you do a bulk insert of gigabyte size you will
> require a gigabyte sized WAL directory.
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
> Tom: If your ratio of physical pages vs WAL records is so bad, the config
> should simply be changes to do fewer checkpoints (say every 20 min like a
> typical Informix setup).
I was using the default configuration. What caused the problem w
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
> foreach tuple in heap that can be deleted do:
> foreach index
> call the current "index delete" with constructed key and xtid
See discussion with Hiroshi. This is much more complex than TID-based
delete and would be faster
