On Mon, 2003-11-03 at 09:38, Tom Lane wrote:
> Neil Conway <[EMAIL PROTECTED]> writes:
> > Given a Relation and an advice, this would:
> > (a) propagate the advice for this relation to all the open FDs for the
> > relation
>
> "All"? You cannot affect the FDs being used by other backends.
Sorry, I meant just the FDs opened by this backend.
> It's fairly unclear to me what the posix_fadvise function is really
> going to do for files that are being accessed by multiple processes.
In a thread on lkml[1], Andrew Morton comments:
Note that it applies to a file descriptor. If
posix_fadvise(FADV_DONTNEED) is called against a file
descriptor, and someone else has an fd open against the same
file, that other user gets their foot shot off. That's OK.
I would imagine that by "getting their foot" shot off, Andrew is saying
that FADV_DONTNEED by one process affects any other processes accessing
the same file via a different FD. If I'm misunderstanding what's going
on here, please let me know.
> For instance, is there any value in setting POSIX_FADV_DONTNEED on a
> WAL file, given that every other backend is going to have that same
> file open?
My understanding is that yes, there is value in doing this, for the
reasons mentioned above.
> A related problem is that the smgr uses the same FD to access the same
> relation no matter how many scans are in progress.
Interesting ... I'll have to think some more about this. Thanks for the
suggestions and comments.
-Neil
[1] - http://www.ussg.iu.edu/hypermail/linux/kernel/0203.2/0361.html
The rest of the thread includes an interesting discussion -- I recommend
reading it. The lkml folks actually speculate about what we (OSS DBMS
developers) would find useful in fadvise(), amusingly enough... The
thread starts here:
http://www.ussg.iu.edu/hypermail/linux/kernel/0203.2/0230.html
Finally, Andrew Morton provides some more clarification on what happens
when multiple processes are accessing a file that is fadvise()'d:
http://www.ussg.iu.edu/hypermail/linux/kernel/0203.2/0476.html
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
