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

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Reply via email to