On Wed, Jul 17, 2019 at 11:33 AM Jerry Sievers <gsiever...@comcast.net> wrote: > -> Nested Loop Left Join (cost=251621.81..12300177.37 rows=48 > width=44) > -> Gather (cost=1001.55..270403.27 rows=48 width=40)
> -> Limit (cost=250620.25..250620.27 rows=1 width=20) > -> Gather (cost=1000.00..250452.00 > rows=3706 width=4) One observation is that it's a rescan a bit like the one in the unsuccessful repro attempt I posted, but it has *two* Gather nodes in it (and thus two parallel query DSM segments), and only one of them should be rescanned, and from the backtrace we see that it is indeed the expected one, the one under the Limit operator. Neither of them should be getting unmapped in the leader though and AFAIK nothing happening in the workers could cause this effect, the leader would have to explicitly unmap the thing AFAIK. On Wed, Jul 17, 2019 at 11:42 AM Jerry Sievers <gsiever...@comcast.net> wrote: > mmap(NULL, 287624, PROT_READ|PROT_WRITE, MAP_SHARED, 124, 0) = 0x7f3d011f2000 > mmap(NULL, 262504, PROT_READ|PROT_WRITE, MAP_SHARED, 124, 0) = 0x7f3d011b1000 > munmap(0x7f3d011b1000, 262504) = 0 Ok, there go our two parallel query DSM segments, and there it is being unmapped. Hmm. Any chance you could attach a debugger, and "break munmap", "cont", and then show us the backtrace "bt" when that is reached? -- Thomas Munro https://enterprisedb.com
