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 1q6YvA-00049g-8z for pgsql-hackers@arkaria.postgresql.org; Tue, 06 Jun 2023 15:48:32 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1q6Yv8-00072C-Uh for pgsql-hackers@arkaria.postgresql.org; Tue, 06 Jun 2023 15:48:30 +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 1q6Yv8-000722-I9 for pgsql-hackers@lists.postgresql.org; Tue, 06 Jun 2023 15:48:30 +0000 Received: from anastigmatix.net ([68.171.219.55]) by magus.postgresql.org with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1q6Yv5-000bmD-5n for pgsql-hackers@lists.postgresql.org; Tue, 06 Jun 2023 15:48:29 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=anastigmatix.net; s=default; h=Content-Transfer-Encoding:Content-Type: Message-ID:References:In-Reply-To:Subject:Cc:To:From:Date:MIME-Version:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=hogW3OKXGTPJLZieOh3eoiXEi09FHkDvLhpG9XkVpjo=; b=bMgOHWKHvSAt/b4angUj+d6h5g 6QqjBZEvnzBURpL+GCxCsJaTSTnBzXzK3Pae5MCCzyF2OSVpQf4V3WDUuVazQzdNhkxoaoi4it8Xe Ci9lfhec8BrIdteJxckjcfHd5k5pWQgdUt/HuIpwykGVzD4svUaZ2XQwHE807NSXzNY8Wgedzfz2y +vOctEKiS8VaosHRAisL+6I127MJc1I5vN/H1qJnxfFM2KgTKy6/yDRChiep0SDQUKL6kSZmIB5BG qcwbV+1FIWbm1h02+jGZZqyyuEyi5OCDajhtH6GHQV/YYlTxVsYy59QJG1SH42cRR1llkSowHmRep jh6zLtpA==; Received: from [::1] (port=48110 helo=bay.acenet.us) by bay.acenet.us with esmtpa (Exim 4.96) (envelope-from ) id 1q6Yv2-00HayK-0E; Tue, 06 Jun 2023 11:48:25 -0400 MIME-Version: 1.0 Date: Tue, 06 Jun 2023 11:48:23 -0400 From: chap@anastigmatix.net To: Konstantin Knizhnik Cc: pgsql-hackers@lists.postgresql.org Subject: Re: Let's make PostgreSQL multi-threaded In-Reply-To: <4658520e-5cd0-6242-e54c-c3af0a85890a@garret.ru> References: <31cc6df9-53fe-3cd9-af5b-ac0d801163f4@iki.fi> <4178104.1685978307@sss.pgh.pa.us> <4658520e-5cd0-6242-e54c-c3af0a85890a@garret.ru> User-Agent: Roundcube Webmail/1.6.0 Message-ID: <6c99fe026eea03fd8aac91aac7143301@anastigmatix.net> X-Sender: chap@anastigmatix.net Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - bay.acenet.us X-AntiAbuse: Original Domain - lists.postgresql.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - anastigmatix.net X-Get-Message-Sender-Via: bay.acenet.us: authenticated_id: chap@anastigmatix.net X-Authenticated-Sender: bay.acenet.us: chap@anastigmatix.net X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2023-06-06 08:06, Konstantin Knizhnik wrote: > 7. It will be hard to support non-multithreaded PL languages (like > python), but for example support of Java will be more natural and > efficient. To this I say ... Hmm. Surely, the current situation with a JVM in each backend process (that calls for one) has been often seen as heavier than desirable. At the same time, I am not sure how manageable one giant process with one giant JVM instance would prove to be, either. It is somewhat nice to be able to tweak JVM settings in a session and see what happens, without disrupting other sessions. There may also exist cases for different JVM settings in per-user or per- database GUCs. Like Python with the GIL, it is documented for JNI_CreateJavaVM that "Creation of multiple VMs in a single process is not supported."[1] And the devs of Java, in their immeasurable wisdom, have announced a "JDK Enhancement Proposal" (that's just what these things are called, don't blame Orwell), JEP 411[2][3], in which all of the Security Manager features that PL/Java relies on for bounds on 'trusted' behavior are deprecated for eventual removal with no functional replacement. I'd be even more leery of using one big shared JVM for everybody's work after that happens. Might the work toward allowing a run-time choice between a process or threaded model also make possible some intermediate models as well? A backend process for connections to a particular database, or with particular authentication credentials? Go through the authentication handshake and then sendfd the connected socket to the appropriate process. (Has every supported platform got something like sendfd?) That way, there could be some flexibility to arrange how many distinct backends (and, for Java purposes, how many JVMs) get fired up, and have each sharing sessions that have something in common. Or, would that just require all the complexity of both approaches to synchronization, with no sufficient benefit? Regards, -Chap [1] https://docs.oracle.com/en/java/javase/17/docs/specs/jni/invocation.html#jni_createjavavm [2] https://blogs.apache.org/netbeans/entry/jep-411-deprecate-the-security1 [3] https://github.com/tada/pljava/wiki/JEP-411