On Sat, 7 May 2005, Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
