Florian G. Pflug wrote:
>> You could still leak them (ie, you move to final location and bail
>> before commit) but it seems to narrow the window down significantly.
> That leak could be prevented I think if the COMMIT record indicated
> which files are to be moved, and the actual move happens after the
> flushing the COMMIT record to disk. Probably the move would need to
> happen while we're in the commit critical section too, to guard
> against concurrent checkpoints - but that all seems doable.
It does fix the crash leak. On recovery you could finish the move if
necessary based on commit record.
I do have a question about jamming though. Will the system work if the
file ended up stuck in this folder? Let's say the move destination has a
duplicate file that conflicts, or permissions change under you, or disks
fill.
Clearly one could error out and force the crash / recovery, but avoiding
that would be better. You could also infer where the file actually is
(unmoved) based on the commit record, and perhaps on attempts to use
that relation report an error after re-attempting the move (ie, couldn't
move xxx, disk full / conflict etc) or simply emit a warning and use it
in its pre-move state. This is a *very* narrow case obviously on a well
maintained system, so I lean towards a clear error message and a higher
profile notice without too much fancy footwork.
I didn't post to -hackers because I'm in way over my head...but I enjoy
following the list.
- August