Re: Support Parallel Query Execution in Executor

On Sun, Apr 09, 2006 at 05:54:56PM -0400, Tom Lane wrote:
> Here's a detailed scenario:
>
> 1. Backend X reads page N of a table T, queues a request for N+1.
> 2. While processing page N, backend X gets an error and aborts
> its transaction, thereby dropping all its lmgr locks.
> 3. Backend Y executes a DROP or TRUNCATE on T, which it can
> now do because there's no lock held anywhere on T. There
> are actually two interesting sub-phases of this:
> 3a. Kill any shared buffers holding pages to be deleted.
> 3b. Physically drop or truncate the OS file.
> 4. Bgreader tries to execute the pending read request. Ooops.
>
> If step 4 happens after 3b, the bgreader gets an error. Maybe we could
> kluge that to not cause any serious problems, but the nastier case is
> where 4 happens between 3a and 3b --- the bgreader sees nothing wrong,
> but it's now loaded a shared buffer that must *not* be there.

The way I dealt with this when playing with async i/o for postgres was
to have the initiator mark the buffer I/O-in-progress then send the
request, just like you suggest. This would cause other people to wait
on it. When the request later finished you processed it as usual and
backends waiting would continue.

The appears to be two seperate cases here though, one is to just farm
out the read request to another process (basically aio), the other is
to do actual processing there. The latter is obviously for more useful
but requires a fair bit more infrastructure.

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.