Обсуждение: AW: AW: AW: Vacuum only with 20% old tuples

> Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at> writes:
> >> We scan the log and come upon the rename.
> >> Hmm, there's a file foo and no file bar ... looks like the 
> >> rename didn't get done, so do it.  Ooops.
> 
> > No again. You come upon "starting rename operation" and then either 
> >     no more log records (backend abort)
> > or 
> >     log record "rename succeeded"
> > or
> >     log record "rename failed"  --> transaction abort
> 
> > In this scenario you can decide what to do without second guessing.
> 
> 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.
The backends could not have created a new file of the old name
after "starting rename" beeing last log record. 

Andreas

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.
        regards, tom lane