Re: [sqlsmith] Unpinning error in parallel worker
Thomas Munro <thomas.munro@enterprisedb.com>
From: Thomas Munro <thomas.munro@enterprisedb.com>
To: Jonathan Rudenberg <jonathan@titanous.com>
Cc: Robert Haas <robertmhaas@gmail.com>,
Andreas Seltenreich <seltenreich@gmx.de>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2018-05-23T04:56:16Z
Lists: pgsql-hackers
On Wed, Apr 25, 2018 at 8:15 AM, Jonathan Rudenberg <jonathan@titanous.com> wrote: > On Tue, Apr 24, 2018, at 16:06, Thomas Munro wrote: >> I'll write a patch to fix that unpleasant symptom. While holding >> DynamicSharedMemoryControlLock we shouldn't raise any errors without >> releasing it first, because the error handling path will try to >> acquire it again. That's a horrible failure mode as you have >> discovered. >> >> But that isn't the root problem: we shouldn't be raising that error, >> and I'd love to see the stack of the one process that did that and >> then self-deadlocked. I will have another go at trying to reproduce >> it here today. > > Thanks for the update! > > We have turned off parallel queries (using max_parallel_workers_per_gather = 0) for now, as the production impact of this bug is unfortunately quite problematic. Apologies for the delay... I've tried a few times reproduce the problem in vain. There may be a timing element here. > What will this failure look like with the patch you've proposed? On second thoughts, I think it depends what is going wrong and I'm not entirely sure if the result would necessarily be better. It might be that errors are raised and normal service resumes or it might be that we have tangled up our resources in a bad way. I need to get to the bottom of this. -- Thomas Munro http://www.enterprisedb.com
Commits
-
Use English, instead of internal names, for translatable messages.
- 5c4488478b18 10.0 landed
-
Plug race in dsa_attach.
- fddf45b38097 10.0 landed