Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1f0Cel-0007V1-29 for pgsql-hackers@arkaria.postgresql.org; Sun, 25 Mar 2018 20:54:23 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1f0Cej-0007eY-Mp for pgsql-hackers@arkaria.postgresql.org; Sun, 25 Mar 2018 20:54:21 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1f0Cej-0007dX-Bp for pgsql-hackers@lists.postgresql.org; Sun, 25 Mar 2018 20:54:21 +0000 Received: from mail.postgrespro.ru ([93.174.131.138]) by magus.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1f0Ceb-0000ld-FC for pgsql-hackers@postgresql.org; Sun, 25 Mar 2018 20:54:20 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.postgrespro.ru (Postfix) with ESMTP id 8DEA821C1CF9; Sun, 25 Mar 2018 23:54:11 +0300 (MSK) X-Virus-Scanned: Debian amavisd-new at postgrespro.ru X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-99 required=4 WHITELISTED tests=[] autolearn=unavailable Received: from arthur.localdomain (unknown [94.29.3.222]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.postgrespro.ru (Postfix) with ESMTPSA id 48EA221C1CF7; Sun, 25 Mar 2018 23:54:11 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=postgrespro.ru; s=mail; t=1522011251; bh=QDl9xEUZZnseYHok0/SpWWFMRfHRCrdHpTcDlpcLAjU=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=mFonl9+CZlhn+a9NPB1B6v9ch81F/FvnQ8jj/JFhVQkOpCSXsF9MyCXqQ3IpO4eUP ooAGlID0V2tAGG8lr+ccknrpS3ujRpF2fZIfD145F1bzu55h+KAuqqGqBbG6sIPMYQ wyeizw7sqGodFHdpu/yaMvLiCHPCBeYFXUxoDDNc= Date: Sun, 25 Mar 2018 23:54:10 +0300 From: Arthur Zakirov To: Tom Lane Cc: Tomas Vondra , Pavel Stehule , Andres Freund , Ildus Kurbangaliev , pgsql-hackers Subject: Re: [PROPOSAL] Shared Ispell dictionaries Message-ID: <20180325205408.GA19457@arthur.localdomain> References: <20180319110648.GA32319@zakirov.localdomain> <2ae9588a-f3cb-777d-1958-c76c22225823@2ndquadrant.com> <20180320131149.GA12884@zakirov.localdomain> <20180321090050.GA21751@zakirov.localdomain> <20180322105603.GA23544@zakirov.localdomain> <28250.1521924996@sss.pgh.pa.us> <25186.1521951490@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <25186.1521951490@sss.pgh.pa.us> User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Sun, Mar 25, 2018 at 12:18:10AM -0400, Tom Lane wrote: > My thought was (a) the ROLLBACK case is ok, because the next use of > the dictionary will reload it, and (b) the reload-concurrently-with- > DROP case is annoying, because indeed it leaks, but the window is small > and it probably won't be an issue in practice. We would need to be > sure that the DSM segment goes away at postmaster restart, but given > that I think it'd be tolerable. Of course it'd be better not to have > the race, but I see no easy way to prevent it -- do you? I'm not sure that I understood the second case correclty. Can cache invalidation help in this case? I don't have confident knowledge of cache invalidation. It seems to me that InvalidateTSCacheCallBack() should release segment after commit. But cache isn't invalidated if a backend was terminated after a dictionary reloading. on_shmem_exit() could help, but we need a leaked dictionaries list for that. P.S. I think it isn't right to release all dictionaries segment in InvalidateTSCacheCallBack(). Otherwise any DROP can release all segments. It would be worth to release a specific dictionary. -- Arthur Zakirov Postgres Professional: http://www.postgrespro.com Russian Postgres Company