Horton

Re: "could not reattach to shared memory" on buildfarm member dory

Magnus Hagander <magnus@hagander.net>

View thread View on postgr.es
From: Magnus Hagander <magnus@hagander.net>
To: Stephen Frost <sfrost@snowman.net>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Date: 2018-04-24T07:18:18Z
Lists: pgsql-hackers 
On Tue, Apr 24, 2018 at 1:18 AM, Stephen Frost <sfrost@snowman.net> wrote:

> Greetings,
>
> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
> > So far, dory has failed three times with essentially identical symptoms:
> >
> > 2018-04-23 19:57:10.624 GMT [2240] FATAL:  could not reattach to shared
> memory (key=0000000000000190, addr=00000000018E0000): error code 487
> > 2018-04-23 15:57:10.657 EDT [8836] ERROR:  lost connection to parallel
> worker
> > 2018-04-23 15:57:10.657 EDT [8836] STATEMENT:  select count(*) from
> tenk1 group by twenty;
> > 2018-04-23 15:57:10.660 EDT [3820] LOG:  background worker "parallel
> worker" (PID 2240) exited with exit code 1
> >
> > Now how can this be?  We've successfully reserved and released the
> address
> > range we want to use, so it *should* be free at the instant we try to
> map.
>
> Yeah, that's definitely interesting.
>
> > I guess the good news is that we're seeing this in a reasonably
> > reproducible fashion, so there's some hope of digging down to find
> > out the actual cause.
>
> I've asked Heath to take a look at the system again and see if there's
> any Windows logs or such that might help us understand what's happening.
> AV was disabled on the box, so don't think it's that, at least.
>

Disabled or uninstalled?

Back when I was combating windows AV on a daily basis, this normally did
not have the same effect. Just disabling the AV didn't actually remove the
parts that caused issues, it just hid them. Actual uninstall is what was
required.

-- 
 Magnus Hagander
 Me: https://www.hagander.net/ <http://www.hagander.net/>
 Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>

Commits

  1. Avoid "could not reattach" by providing space for concurrent allocation.

  2. Assert that pgwin32_signal_initialize() has been called early enough.

  3. Remove investigative code for can't-reattach-to-shared-memory errors.

  4. Does it help to wait before reattaching?

  5. Map and unmap the shared memory block before risking VirtualFree.

  6. Further effort at preventing memory map dump from affecting the results.

  7. Remove Windows module-list-dumping code.

  8. Dump full memory maps around failing Windows reattach code.

  9. Get still more info about Windows can't-reattach-to-shared-memory errors.

  10. Get more info about Windows can't-reattach-to-shared-memory errors.

  11. Try to get some info about Windows can't-reattach-to-shared-memory errors.