> Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)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.
pgsql-hackers by date
|Next:||From: Zeugswetter Andreas SB||Date: 2000-07-27 08:21:47|
|Subject: AW: TOAST & vacuum|
|Previous:||From: frank||Date: 2000-07-27 06:39:54|
|Subject: Re: [GENERAL] Is Pg 7.0.x's Locking Mechanism BROKEN?|