Re: libpq and multi-threading - Mailing list pgsql-general

From Peter J. Holzer
Subject Re: libpq and multi-threading
Date
Msg-id 20230502175759.afgnyhkq3pwkwq4g@hjp.at
Whole thread Raw
In response to Re: libpq and multi-threading  ("Michael J. Baars" <mjbaars1977.pgsql.hackers@gmail.com>)
Responses Re: libpq and multi-threading  ("Michael J. Baars" <mjbaars1977.pgsql.hackers@gmail.com>)
List pgsql-general
On 2023-05-02 17:43:06 +0200, Michael J. Baars wrote:
> I don't think it is, but let me shed some more light on it.

One possibly quite important information you haven't told us yet is
which OS you use.

Or how you create the threads, how you pass the results around, what
else you are possibly doing between getting the result and trying to use
it ...

A short self-contained test case might shed some light on this.


> After playing around a little with threads and memory, I now know that the
> PGresult is not read-only, it is read-once. The child can only read that
> portion of parent memory, that was written before the thread started. Read-only
> is not strong enough.
>
> Let me correct my first mail. Making libpq use mmap is not good enough either.
> Shared memory allocated by the child can not be accessed by the parent.

Are you sure you are talking about threads and not processes? In the OSs
I am familiar with, threads (of the same process) share a common address
space. You don't need explicit shared memory and there is no such thing
as "parent memory" (there is thread-local storage, but that's more a
compiler/library construct).

        hp

--
   _  | Peter J. Holzer    | Story must make more sense than reality.
|_|_) |                    |
| |   | hjp@hjp.at         |    -- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |       challenge!"

Attachment

pgsql-general by date:

Previous
From: "Michael J. Baars"
Date:
Subject: Re: libpq and multi-threading
Next
From: Tomas Pospisek
Date:
Subject: Re: Regarding SSL Enablement in PostgreSQL Database on different port