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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
