
> Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at> writes:
> >> If there are no more records, then you are reduced to 
> guessing whether
> >> you have to undo the rename or not.  If you guess wrong, 
> you leave the
> >> database in a corrupted state.
> 
> > If the original filename exists the rename failed else it succeeded.
> 
> That's exactly the unreliable assumption I do not want to make.
> 
> > The backends could not have created a new file of the old name
> > after "starting rename" beeing last log record. 
> 
> So you're assuming that we fsync() the log after *each* item is added?
> *Within* a transaction?  fsync only at end of xact was the plan,
> I believe.

With trx log we imho would not need any fsyncs anymore
(except maybe checkpoints).
We would open the trxlog file with O_SYNC and only do a write
when it is absolutely necessary (buffer overflow, end of trx).
But yes the rename log entries (only those) would need to be 
written immediately. Is this a performance issue? I guess not.

Andreas

Thu, 27 Jul 2000 10:09:29 +0200
Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>
AW: AW: AW: AW: Vacuum only with 20% old tuples 
Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at> writes:
> But yes the rename log entries (only those) would need to be 
> written immediately. Is this a performance issue? I guess not.

Two fsyncs per rename is probably not a performance killer, but you'd
have to also fsync log entries for file creates and deletes, which
might be a bigger deal.

			regards, tom lane

Thu, 27 Jul 2000 10:03:42 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: AW: AW: AW: AW: Vacuum only with 20% old tuples 