AW: AW: AW: AW: Vacuum only with 20% old tuples
От | Zeugswetter Andreas SB |
---|---|
Тема | AW: AW: AW: AW: Vacuum only with 20% old tuples |
Дата | |
Msg-id | 11C1E6749A55D411A9670001FA687963368031@sdexcsrv1.f000.d0188.sd.spardat.at обсуждение исходный текст |
Ответы |
Re: AW: AW: AW: AW: Vacuum only with 20% old tuples
|
Список | pgsql-hackers |
> 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
В списке pgsql-hackers по дате отправления: