On Tue, Feb 12, 2019 at 4:01 PM Justin Pryzby <pryzby@telsasoft.com> wrote:
> On Mon, Feb 11, 2019 at 08:43:14PM -0600, Justin Pryzby wrote:
> > I have a suspicion that this doesn't happen if
> > parallel_leader_participation=off.
>
> I think this is tentatively confirmed..I ran 20 loops for over 90 minutes with
> no crash when parallel_leader_participation=off.
>
> On enabling parallel_leader_participation, crash within 10min.
That's quite interesting. I wonder if it's something specific about
the leader's behaviour, or if it's just because it takes one more
process to hit the bad behaviour on your system.
> Sergei, could you confirm ?
>
> Thomas:
>
> 2019-02-11 23:56:20.611 EST [12699] PANIC: dsa_area could not attach to segment index:6 handle:1376636277
> [pryzbyj@telsasoft-db postgresql]$ ls /dev/shm/ |grep PostgreSQL.1376636277 || echo Not present.
> Not present.
Ok, based on the absence of the file, it seems like we destroyed it
but didn't remove the segment from our the list (unless of course it's
a bogus handle that never existed). Perhaps that could happen if the
DSM segment's ref count got out of whack so it was destroyed too soon,
or if it didn't but our list manipulation code is borked or somehow we
didn't reach it or something concurrent confused it due to
insufficient locking or data being overwritten...
I need to reproduce this and load it up with instrumentation and
checks. Will keep trying.
Were you running with assertions enabled?
--
Thomas Munro
http://www.enterprisedb.com
