On Thu, Feb 21, 2019 at 4:36 AM Hans Buschmann <buschmann@nidsa.net> wrote:
> I encountered this problem after switching the production system and then found it also on the new created replica.
>
> I have no knowledge of the shared memory areas involved.
>
> I did some further investigation and tried to reproduce it on the old System (WS2016, PG 11.2) but there it worked
fine(without and with huge pages activated!).
>
> Even on a developer machine under WS2019, PG 11.2 the error did not occur (both cases running on different generation
ofintel machines, Haswell and Nehalem, under different Hypervisors, WS2012R2 and WS2019).
>
> I am really confused to not being able to reproduce the error outside of production and replica instances...
>
> The error caused a massive flood of the logs (about 800 MB in about 1 day, on SSD)
>
> I'll try to investigate further by configuring a second replica tomorrow, using the configuration of the production
systemas done per pg_basebackup.
Just to confirm: on the machines where it happens, does it happen on
every restart, and does it never happen if you set huge_pages = off?
CC'ing the authors of the auto-prewarm feature to see if they have ideas.
There is a known bug (fixed in commit 6c0fb941 for the next release)
that would cause spurious dsm_attach() failure that would look just
this this (dsm_attach() returns NULL), but that should be very rare
and couldn't cause the behaviour described here, because here the
background worker is repeatedly failing to attach in a loop (hence the
800MB of logs).
--
Thomas Munro
https://enterprisedb.com