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 1kiJ7N-0007g3-4R for pgsql-hackers@arkaria.postgresql.org; Thu, 26 Nov 2020 15:23:33 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kiJ7M-0007wA-3Z for pgsql-hackers@arkaria.postgresql.org; Thu, 26 Nov 2020 15:23:32 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kiJ7L-0007w2-Su for pgsql-hackers@lists.postgresql.org; Thu, 26 Nov 2020 15:23:31 +0000 Received: from oss.nttdata.com ([49.212.34.109]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kiJ7I-0006Hq-Vp for pgsql-hackers@postgresql.org; Thu, 26 Nov 2020 15:23:31 +0000 Received: from hnk.local (p1295030-ipngn4902funabasi.chiba.ocn.ne.jp [153.166.85.30]) by oss.nttdata.com (Postfix) with ESMTPSA id C3D5560256; Fri, 27 Nov 2020 00:23:23 +0900 (JST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.102.3 at oss.nttdata.com Subject: Re: Use standard SIGHUP and SIGTERM handlers in autoprewarm module To: Bharath Rupireddy Cc: Craig Ringer , PostgreSQL-development , Robert Haas References: <13156732-5189-af54-3d28-e2ee2a8568e0@oss.nttdata.com> <069fb3bc-3907-4d85-19fd-e4b2d2f004b4@oss.nttdata.com> <1ae40b1b-2f42-4510-1514-40bb7d7255ab@oss.nttdata.com> <3f292fbb-f155-9a01-7cb2-7ccc9007ab3f@oss.nttdata.com> <8a7c4f21-ccee-b454-a265-c6b788b5c5d1@oss.nttdata.com> From: Fujii Masao Message-ID: Date: Fri, 27 Nov 2020 00:23:23 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2020/11/27 0:15, Bharath Rupireddy wrote: > On Thu, Nov 26, 2020 at 7:37 PM Fujii Masao wrote: >> >>> What do you mean by normal shutdown of bgworker? Is it that bgworker has exited successfully with exit code 0 or for some reason with exit code other than 0? Or is it when the postmaster is shutdown normally? >>> >>> IIUC, when a bgworker exists either normally with an exit code 0 or other than 0, then CleanupBackgroundWorker() is called in postmaster, a message(like below) is prepared, and the LogChildExit() is called with either DEBUG1 or LOG level and for instance the message you specified gets printed "background worker ... exited with exit code 1". I have not seen a FATAL message similar to "background worker ... exited with exit code 1" at the normal shutdown. >>> >>> snprintf(namebuf, MAXPGPATH, _("background worker \"%s\""), rw->rw_worker.bgw_type); >>> >>> LogChildExit(EXIT_STATUS_0(exitstatus) ? DEBUG1 : LOG, namebuf, pid, exitstatus); >>> >>> Am I missing something? >>> >>> If my analysis is right, then for instance, when a logical replication launcher is exited, it logs "background worker "logical replication launcher" exited with exit code X" with either DEBUG1 or LOG level but not with FATAL level. >> >> Yes, it's not with FATAL level. But that message looks like that it's >> reporting error message. This is why we sometimes received >> the complaints (e.g., [1][2]) about that message. >> > > Oh. Should we do something about it now? No. This is not directly related to the issue that we are discussing as I told upthread. Of course, it's better to work on this if we can easily fix it. But seems not... So please ignore this my comment. Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION