Knizhnik made these variables thread local, which is fine if you have a fixed association of threads to data. This looses some flexibility if your runtime needs to incorporate multiple sessions on one thread (for example to hide IO latency) in the future. In the end, the best solution is to associate the data that belongs to a session with the session itself, making it independent on which thread it's running on. This is described by Knizhnik as "cumbersome", which is exactly why people should have not started with global variables in the first place. (No blame, Postgres is from 1986 and times were very different back then).
PostgreSQL uses a process model. So the article just states that globals work fine for PostgreSQL
> Knizhnik has already done a threads port of PostgreSQL. The global-variable problem, he said, was not that difficult.
I see no big problem based on information from person who did some porting already.