The following bug has been logged online:

Bug reference: 2442
Logged by: Carmen
Email address: carmenlucia@globo.com
PostgreSQL version: 8.0
Operating system: FreeBSD
Description: Problemas accessing DB in a multithread pross
Details:

I have a Windows system accesing a FreeBSD PostGres 8.0.
I have a multihread process in Windows using a PostGres 8.0 FreeBSD. Each
thread of this process has a TCP communicaction with a remote client and it
updates a common BD of the global process.
TEach time two threads access a SQL API at the axact sametiem, the
process(not just the thread) is aborted. I resolved this problem defining a
critical section for each API SQL acess, but it has been causing a great
delay in my realtime program.
This problema happens, even if my BD is a local Windows PostGres.
This Windows program was migrated from Linux. Linux uses fork for each
remote client, and I don´t have this kind of problem with fork.
So, why have I this problem with threads. Is this a limitation?
I must solve this problem to put it in production. The critical_section has
not been a godd soluction. Can you help me?

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

""Carmen"" <carmenlucia@globo.com> wrote
>
> I have a Windows system accesing a FreeBSD PostGres 8.0.
> I have a multihread process in Windows using a PostGres 8.0 FreeBSD. Each
> thread of this process has a TCP communicaction with a remote client and
it
> updates a common BD of the global process.
> TEach time two threads access a SQL API at the axact sametiem, the
> process(not just the thread) is aborted. I resolved this problem defining
a
> critical section for each API SQL acess, but it has been causing a great
> delay in my realtime program.
>

What SQL API exactly? I once rewrite Pgbench (the TPCB benchmark) as a
multi-threaded version in Windows, there is no obvious problem (the patch
can be found in pg-patches). Just to make sure that each thread use a
different connection.

Regards,
Qingqing