Re: Extended Prefetching using Asynchronous IO - proposal and patch

My cut'n'pasting failed me at one point corrected below.

> discussion about what is the difference between a synchronous read
> versus an asynchronous read as far as non-originator waiting on it is concerned.
>
> I thought a bit more about this. There are currently two differences,
> one of which can easily be changed and one not so easy.
>
> 1) The current code, even with sigevent, still makes the non-originator waiter
> call aio_error on the originator's aiocb to get the completion code.
> For sigevent variation, easily changed to have the originator always call aio_error
> (from its CHECK_INTERRUPTS or from FIleCompleteaio)
> and store that in the BAiocb.
> My idea of why not to do that was that, by having the non-originator check the aiocb,
> this would allow the waiter to proceed sooner. But for a different reason it actually
> doesn't. (The non-originator must still wait for the LWlock release)
>
> 2) Buffer pinning and returning the BufferAiocb to the free list
> With synchronous IO, each backend that calls a ReadBuffer must pin the buffer
> early in the process.
> With asynchronous IO, initially only the originator gets the pin
> (and that is during PrefetchBuffer, not Readbuffer)
> When the aio completes and some backend checks that completion,
> then the backend has various responsibilities:
>
> . pin the buffer if it did not already have one (from prefetch)
> . if it was the last such backend to make that check
> (amongst the cohort waiting on it)
> then XXXXXXpin the buffer if it did not already have one (from prefetch)XXXX

then return the BufferAiocb to the free list