Skip site navigation (1) Skip section navigation (2)

AW: AW: AW: AW: Vacuum only with 20% old tuples

From: Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at>
To: "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "'Hiroshi Inoue'" <Inoue(at)tpf(dot)co(dot)jp>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: AW: AW: AW: AW: Vacuum only with 20% old tuples
Date: 2000-07-27 08:09:29
Message-ID: 11C1E6749A55D411A9670001FA687963368031@sdexcsrv1.f000.d0188.sd.spardat.at (view raw or flat)
Thread:
Lists: pgsql-hackers
> 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.

Andreas

Responses

pgsql-hackers by date

Next:From: Zeugswetter Andreas SBDate: 2000-07-27 08:21:47
Subject: AW: TOAST & vacuum
Previous:From: frankDate: 2000-07-27 06:39:54
Subject: Re: [GENERAL] Is Pg 7.0.x's Locking Mechanism BROKEN?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group