On Sat, 7 May 2005, Tom Lane wrote:
> Heikki Linnakangas <hlinnaka@iki.fi> writes:
>> Maybe we should take a different approach to the problem:
>> 1. Create new file with an extension to mark that it's not
>> yet committed (eg. 1234.notcommitted)
>
> This is pushing the problem into the wrong place, viz the lowest-level
> file access routines, which will now all have to know about
> .notcommitted status. It also creates race conditions --- think about
> backend A trying to commit file 1234 at about the same time that
> backend B is trying to flush some dirty buffers belonging to that file.
True. With the rename variant, it might indeed get messy.
Consider the variant with extra marker files. In that case, backend B
doesn't have to know about the .notcommitted status to flush the buffers.
> But most importantly, it doesn't handle the file-deletion case.
File-deletions are easy to handle. Just write the list of pending
deletions to WAL on commit.
To recap, we have 2 slightly different scenarios:
a) Delete a file, write commit record, crash
b) Create a file, crash
Just WAL logging the deletions on commit would take care of A. The
.notcommitted mechanism would take care of B.
- Heikki
