Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kWMoH-0007NT-Ux for pgsql-bugs@arkaria.postgresql.org; Sat, 24 Oct 2020 16:54:29 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kWMoG-0003YD-Ma for pgsql-bugs@arkaria.postgresql.org; Sat, 24 Oct 2020 16:54:28 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kWMoG-0003Y0-GU for pgsql-bugs@lists.postgresql.org; Sat, 24 Oct 2020 16:54:28 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kWMoE-0001gA-5I for pgsql-bugs@lists.postgresql.org; Sat, 24 Oct 2020 16:54:27 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 09OGsNBS380145; Sat, 24 Oct 2020 12:54:23 -0400 From: Tom Lane To: exclusion@gmail.com cc: pgsql-bugs@lists.postgresql.org Subject: Re: BUG #16685: The ecpg thread/descriptor test fails sometimes on Windows In-reply-to: <367782.1603554604@sss.pgh.pa.us> References: <16685-d6cd241872c101d3@postgresql.org> <367782.1603554604@sss.pgh.pa.us> Comments: In-reply-to Tom Lane message dated "Sat, 24 Oct 2020 11:50:04 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <380143.1603558463.1@sss.pgh.pa.us> Date: Sat, 24 Oct 2020 12:54:23 -0400 Message-ID: <380144.1603558463@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk I wrote: > I'll bet that the correct fix is > static void > set_descriptors(struct descriptor *value) > { > + pthread_once(&descriptor_once, descriptor_key_init); > pthread_setspecific(descriptor_key, value); > } No, looking closer, there are only two calls of set_descriptors() and each of them is preceded by a call to get_descriptors(). So it should not be possible to get here without descriptor_key having been initialized. I'm forced to the conclusion that there's something wrong with ECPG's emulation of pthread_once ... ... and now that I look at it, it seems just as obvious what is wrong there: void win32_pthread_once(volatile pthread_once_t *once, void (*fn) (void)) { if (!*once) { pthread_mutex_lock(&win32_pthread_once_lock); if (!*once) { *once = true; fn(); } pthread_mutex_unlock(&win32_pthread_once_lock); } } We should not set *once until AFTER we execute fn(). Otherwise, other threads passing through pthread_once() will mistakenly fall through, expecting the initialization to be done already. (So in this view, adding a sleep just before fn() would make the failure more reproducible.) regards, tom lane