Re: [HACKERS] Anyone understand shared buffer refcount mechanism?
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Anyone understand shared buffer refcount mechanism? |
Дата | |
Msg-id | 13641.937836472@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Anyone understand shared buffer refcount mechanism? (Vadim Mikheev <vadim@krs.ru>) |
Список | pgsql-hackers |
Vadim Mikheev <vadim@krs.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
В списке pgsql-hackers по дате отправления: