On Sat, Feb 18, 2017 at 10:45 PM, Dilip Kumar <dilipbal...@gmail.com> wrote: > in 0002: > - Improved comments. > - Code refactoring in BitmapHeapNext. > - Removed local tbm creation in BitmapHeapNext : as per new tidbitmap > it's of no use.
I have observed one problem with 0002 and I though of sharing that before fixing the same because we might have encountered the same problem in some other patches i.e parallel shared hash and there might be already a way to handle that. The problem is that In ExecEndBitmapHeapScan we do tbm_free. Wherein, it frees local pagetable memory and the shared memory using callback routine and if other than the Backend (actual backend for the client which is executing gather node) node any other worker become the leader (worker which is responsible for creating the shared TBM) then it will finish it work and free the shared memory by calling ExecEndBitmapHeapScan, and it's possible that other worker are still operating on the shared memory. So far I never observed this issue in our test may be because either Backend become the leader or by the time leader (non backend) free the TBM others also finishes there work. Solution: - One solution to this problem can be that leader should not complete the scan unless all other worker have finished the work. - We can also think of that we don't make anyone wait but we make a arrangement that last worker to finish the bitmapscan only free the memory, but one problem with this solution is that last worker can be non-leader also, which will have access to shared memory but how to free the pagetable local memory (it's local to the leader). Any suggestion on this ? -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
