Re: Let's make PostgreSQL multi-threaded

From: chap(at)anastigmatix(dot)net
To: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Cc: Konstantin Knizhnik <knizhnik(at)garret(dot)ru>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Let's make PostgreSQL multi-threaded
Date: 2023-06-06 17:00:11
Message-ID: ff642e48c9b52427034d40d929457888@anastigmatix.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2023-06-06 12:24, Heikki Linnakangas wrote:
> I'm afraid having multiple processes and JVMs doesn't help that.
> If you can escape the one JVM in one backend process, it's game over.

So there's escape and there's escape, right? Java still prioritizes
(and has, in fact, strengthened) barriers against breaking module
encapsulation, or getting access to arbitrary native memory or code.

The features that have been deprecated, to eventually go away, are
the ones that offer fine-grained control over operations that there
are Java APIs for. Eventually it won't be as easy as it is now to say
"ok, your function gets to open these files or these sockets but
not those ones."

Even for those things, there may yet be solutions. There are Java
APIs for virtualizing the view of the file system, for example. It's
yet to be seen how things will shake out. Configuration may get
trickier, and there may be some incentive to to include, say,
sepgsql in the picture.

Sure, even access to a file API can be game over, depending on
what file you open, but that's already the risk for every PL
with an 'untrusted' flavor.

Regards,
-Chap

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Laurenz Albe 2023-06-06 17:00:57 Re: Return value of pg_promote()
Previous Message Laurenz Albe 2023-06-06 16:57:57 Re: ERROR: could not determine which collation to use for string comparison