Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Mon, 05 Jun 2023 10:28:50 -0500
Subject: Re: Let's make PostgreSQL multi-threaded
To: "Heikki Linnakangas" <hlinnaka@iki.fi>, "pgsql-hackers"
 <pgsql-hackers@postgresql.org>
From: "Tristan Partin" <tristan@neon.tech>
Message-Id: <CT4TNFJFKOY3.22XP8JDT7U0C5@gonk>
References: <31cc6df9-53fe-3cd9-af5b-ac0d801163f4@iki.fi>
In-Reply-To: <31cc6df9-53fe-3cd9-af5b-ac0d801163f4@iki.fi>
Archived-At: <https://www.postgresql.org/message-id/CT4TNFJFKOY3.22XP8JDT7U0C5%40gonk>
Precedence: bulk

On Mon Jun 5, 2023 at 9:51 AM CDT, Heikki Linnakangas wrote:
> # Global variables
>
> We have a lot of global and static variables:
>
> $ objdump -t bin/postgres | grep -e "\.data" -e "\.bss" | grep -v=20
> "data.rel.ro" | wc -l
> 1666
>
> Some of them are pointers to shared memory structures and can stay as=20
> they are. But many of them are per-connection state. The most=20
> straightforward conversion for those is to turn them into thread-local=20
> variables, like Konstantin did in [0].
>
> It might be good to have some kind of a Session context struct that we=20
> pass everywhere, or maybe have a single thread-local variable to hold=20
> it. Many of the global variables would become fields in the Session. But=
=20
> that's future work.

+1 to the session context idea after the more simple thread_local
storage idea.

> # Extensions
>
> A lot of extensions also contain global variables or other things that=20
> break in a multi-threaded environment. We need a way to label extensions=
=20
> that support multi-threading. And in the future, also extensions that=20
> *require* a multi-threaded server.
>
> Let's add flags to the control file to mark if the extension is=20
> thread-safe and/or process-safe. If you try to load an extension that's=
=20
> not compatible with the server's mode, throw an error.
>
> We might need new functions in addition _PG_init, called at connection=20
> startup and shutdown. And background worker API probably needs some chang=
es.

It would be a good idea to start exposing a variable through pkg-config
to tell whether the backend is multi-threaded or multi-process.

> # Exposed PIDs
>
> We expose backend process PIDs to users in a few places.=20
> pg_stat_activity.pid and pg_terminate_backend(), for example. They need=
=20
> to be replaced, or we can assign a fake PID to each connection when=20
> running in multi-threaded mode.

Would it be possible to just transparently slot in the thread ID
instead?

> # Thread-safe libraries
>
> Need to switch to thread-safe versions of library functions, e.g.=20
> uselocale() instead of setlocale().

Seems like a good starting point.

> The Python interpreter has a Global Interpreter Lock. It's not possible=
=20
> to create two completely independent Python interpreters in the same=20
> process, there will be some lock contention on the GIL. Fortunately, the=
=20
> python community just accepted https://peps.python.org/pep-0684/. That's=
=20
> exactly what we need: it makes it possible for separate interpreters to=
=20
> have their own GILs. It's not clear to me if that's in Python 3.12=20
> already, or under development for some future version, but by the time=20
> we make the switch in Postgres, there probably will be a solution in=20
> cpython.

3.12 is the currently in-development version of Python. 3.12 is planned
for release in October of this year.

A workaround that some projects seem to do is to use multiple Python
interpreters[0], though it seems uncommon. It might be important to note
depending on the minimum version of Python Postgres aims to support (not
sure on this policy).

The C-API of Python also provides mechanisms for releasing the GIL. I am
not familiar with how Postgres uses Python, but I have seen huge
improvements to performance with well-placed GIL releases in
multi-threaded contexts. Surely this API would just become a no-op after
the PEP is implemented.

[0]: https://peps.python.org/pep-0684/#existing-use-of-multiple-interpreter=
s

--=20
Tristan Partin
Neon (https://neon.tech)