Internals question about buffers

I received this question about buffer management. Can someone answer it?

---------------------------------------------------------------------------

nield(at)usol(dot)com wrote:
>
> Dear Mr. Momjian:
>
> First let me thank you for the great work you have done on PostgreSQL.
> This is a huge project, and as someone who is just starting to look at
> the code I'm grateful for the effort that has gone into commenting and
> clean module interfaces.
>
> Right now, I'm working on a draft proposal involving the WAL system,
> in the perhaps vain hope of eliminating VACUUM and allowing
> point-in-time recovery and play-forward file recovery from a saved
> log-stream. I'm not ready yet to make the proposal, since I'm still
> trying to figure out everything I need to know about PostgreSQL
> internals, but I hope to have a Request for Comments I can post to the
> pgsql-hackers list in the near future.
>
> The reason I'm writing you is because while looking at the buffer
> manager, I had a question about locking and extending relations. There
> is surely somthing I don't understand that explains why this scenerio
> is not a problem, but if you could point out what I've missed it would
> help me understand PostgreSQL better, and move me closer to being able
> to contribute to the project.
>
> Please feel free to forward this to the pgsql-hackers list if you
> don't have time to deal with it.
>
> Regards,
>
> J.R. Nield <nield(at)usol(dot)com>
>
>
>
>
>
>
> [see the scenerio at bottom first]
>
> Is there a race condition in ReadBufferInternal() ?
> (From bufmgr.c,v 1.123 2002/04/15 23:47:12 momjian Exp)
>
> When blockNum argument to ReadBufferInternal is 'P_NEW', then
> smgrnblocks() is called on the relation to get the last block in the
> relation file. This is assigned to blockNum, and the function proceeds
> as if ReadBufferInternal() were called with a blockNum equal to
> smgrnblocks().
>
> Two things to note:
>
> A) The BufMgrLock is not held when smgrnblocks() is called. (unless
> bufferLockHeld was true, which will not be the case when we're
> called through ReadBuffer() )
>
> B) ReadBufferInternal() then gets an exclusive lock on BufMgrLock
> and calls BufferAlloc().
>
> If between Time A and B another backend allocates a buffer with P_NEW,
> then BufferAlloc() will find the buffer in the block cache.
>
> If so, it would seem like there is a problem, because later in the
> function we will zero this block.
>
> On line 198, we check if the block was found (Yes), then if we were
> expecting it (No) we return. If the buffer is local (It is not) we
> do StartBufferIO().
>
> The next thing is at 224 where isExtend == true, so we zero the
> block.
>
> *** Why is it OK to zero the block? ***
>
> Scenerio:
>
> PROC1 and PROC2 both call ReadBuffer(reln, P_NEW) -->
> ReadBufferInternal(reld, P_NEW, false)
>
> PROC1 gets NOT FOUND from BufferAlloc, so it zero's the buffer and
> calls smgrextend.
>
> PROC2 finds the buffer and waits in WaitIO() for PROC1 to complete.
>
> PROC1 finishes ReadBuffer and goes on to modify the buffer.
>
> PROC2 gets a FOUND buffer from BufferAlloc, but was expecting to
> extend. It zero's the buffer and calls smgrextend, stomping on PROC1.
>
>
>
>
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026