> Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)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.
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2000-07-26 15:12:08|
|Subject: Re: Some questions on user defined types and functions. |
|Previous:||From: Tom Lane||Date: 2000-07-26 14:46:27|
|Subject: Re: Is Pg 7.0.x's Locking Mechanism BROKEN? |