Re: test_shm_mq failing on mips*

From: Christoph Berg <cb(at)df7cb(dot)de>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Andres Freund <andres(at)2ndquadrant(dot)com>, Dave Page <dave(dot)page(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, CM Team <cm(at)enterprisedb(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, bernd(dot)helmle(at)credativ(dot)de
Subject: Re: test_shm_mq failing on mips*
Date: 2014-12-02 15:59:37
Message-ID: 20141202155936.GA24713@msg.df7cb.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Re: Robert Haas 2014-12-02 <CA+Tgmoa9HE=1GObU7MKuGLDBjBNSNRW0bDE4P3JA=P=9mqGgqw(at)mail(dot)gmail(dot)com>
> I can't tell from this exactly what's going wrong. Questions:
>
> 1. Are there any background worker processes running at the same time?
> If so, how many? We'd expect to see 3.
> 2. Can we printout of the following variables in stack frame 3
> (test_shm_mq_pipelined)? send_count, loop_count, *outqh, *inqh,
> inqh->mqh_queue[0], outqh->mqh_queue[0]
> 3. What does a backtrace of each background worker process look like?
> If they are stuck inside copy_messages(), can you print *outqh, *inqh,
> inqh->mqh_queue[0], outqh->mqh_queue[0] from that stack frame?
>
> Sorry for the hassle; I just don't have a better idea how to debug this.

No problem, I'm aware this isn't an easy target.

I didn't have access to the build env myself, I'm not sure if I can
find someone to retry the test there. I'll let you know when I have
more data, but that will take a while (if at all :-/).

Christoph
--
cb(at)df7cb(dot)de | http://www.df7cb.de/

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2014-12-02 16:22:07 Re: initdb: Improve error recovery.
Previous Message Robert Haas 2014-12-02 15:55:36 Re: copy.c handling for RLS is insecure