On Wed, Jul 17, 2019 at 11:33 AM Jerry Sievers <gsievers19@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 <gsievers19@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