Re: [HACKERS] Anyone understand shared buffer refcount mechanism?

Vadim Mikheev <vadim(at)krs(dot)ru> writes:
> Tom Lane wrote:
>> In trying to understand what the code is doing, I am confused by the
>> buffer refcount save/restore mechanism. Why does the executor want
>> to save/restore buffer refcounts? I can sort of see that that might

> This bothered me for long time too.
> The only explanation I see in execMain.c:

> * this makes sure that when ExecutorRun's are called recursively as for
> * postquel functions, the buffers pinned by one ExecutorRun will not
> * be unpinned by another ExecutorRun.

The case that is currently failing for me is postquel function calls
(the "misc" regress test contains some, and it's spewing Buffer Leak
notices like crazy, now that I fixed BufferLeakCheck to notice nonzero
LastRefCount as well as nonzero PrivateRefCount). So there's something
rotten here. I will keep looking at it.

> So, try to remove this save/restore mechanism and let's see...

It does seem that BufferRefCountRestore is actually unpinning some
things (things got much better after I fixed it to really do the
unpin when restoring a nonzero refcount to zero). So I don't
think I want to try to take out the save/restore entirely. What
it looks like right now is that a few specific paths through the
executor restore the wrong counts...

regards, tom lane