On Thu, Sep 15, 2016 at 5:22 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> Of course, it's also possible that the ParallelWorkerNumber code is
>> entirely correct and something overwrote the null bytes that were
>> supposed to be found at that location. It would be very useful to see
>> (a) the value of ParallelWorkerNumber and (b) the contents of
>> vmq->mq_sender, and in particular whether that's actually a valid
>> pointer to a PGPROC in the ProcArray. But unless we can reproduce
>> this I don't see how to manage that.
>
> Is it worth replacing that Assert with a test-and-elog that would
> print those values?
>
> Given that we've seen only one such instance in the buildfarm, this
> might've been just a cosmic ray bit-flip. So one part of me says
> not to worry too much until we see it again. OTOH, if it is real
> but rare, missing an opportunity to diagnose would be bad.
I wonder if we could persuade somebody to run pgbench on a Windows
machine with a similar environment, at least some concurrency, and
force_parallel_mode=on. Assuming this is a generic
initialize-the-parallel-stuff bug and not something specific to a
particular query, that might well trigger it a lot quicker than
waiting for it to recur in the BF.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
