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 (
To make changes to your subscription:

Reply via email to