On Mon, Jun 23, 2014 at 2:43 PM, John Lumby <johnlu...@hotmail.com> wrote: > It is when some *other* backend gets there first with the ReadBuffer that > things are a bit trickier. The current version of the patch did polling > for that case > but that drew criticism, and so an imminent new version of the patch > uses the sigevent mechanism. And there are other ways still.
I'm a bit puzzled by this though. Postgres *already* has code for this case. When you call ReadBuffer you set the bits on the buffer indicating I/O is in progress. If another backend does ReadBuffer for the same block they'll get the same buffer and then wait until the first backend's I/O completes. ReadBuffer goes through some hoops to handle this (and all the corner cases such as the other backend's I/O completing and the buffer being reused for another block before the first backend reawakens). It would be a shame to reinvent the wheel. The problem with using the Buffers I/O in progress bit is that the I/O might complete while the other backend is busy doing stuff. As long as you can handle the I/O completion promptly -- either in callback or thread or signal handler then that wouldn't matter. But I'm not clear that any of those will work reliably. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
