BTW, what is the value of using posix_fadvise() in warm_fcache? ISTM that if you're worried about waiting for I/O while holding the LWLock (as I concur you should be), this coding is entirely inadequate for preventing that, as the whole point of posix_fadvise is that it won't wait around for the I/O to happen. It strains credulity to the breaking point to imagine that the kernel will have gotten around to reading the file in the small number of nanoseconds that will elapse before you start needing the data. Unless of course the file is already in buffers, but then the whole thing was a waste of code.
I think we should flush the posix_fadvise() code path as being neither useful nor portable, and just do the actual read() as in the other path (which btw is lacking an essential fseek). Actually, I think the whole thing is rather badly designed, as warm cache or no you're still proposing to do thousands of kernel calls while holding a potentially contended LWLock. I suggest what we do is (1) read in the whole file, (2) acquire the lock, (3) re-read the whole file in the same buffer, (4) work from the buffer. It might be possible to optimize the re-read away in the common case that the file didn't actually change since we started to read it; we'd need to put a bit more reporting into qtext_store probably, so that it's possible to tell if any space is reserved but still unwritten. BTW shouldn't there be an fflush() in qtext_store? We could also eliminate some palloc/pfree cycles by using the string directly in the buffer (at the small cost of needing to include the strings' trailing nulls in the file). regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers