Re: Extending SQL with C, shared library problem - Mailing list pgsql-novice

From Shawn Garbett
Subject Re: Extending SQL with C, shared library problem
Date
Msg-id 20050720220316.5615.qmail@web54407.mail.yahoo.com
Whole thread Raw
In response to Re: Extending SQL with C, shared library problem  (Shawn Garbett <shawn_garbett@yahoo.com>)
List pgsql-novice
--- Shawn Garbett <shawn_garbett@yahoo.com> wrote:
> --- Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> > Shawn Garbett <shawn_garbett@yahoo.com> writes:
> > > I've got C code written to store a value in the
> > > context of an active connection using a hash. It
> > > worked until I added some semaphores to control
> > memory
> > > reads/writes to the shared resource. This is on
> > SLES9
> > > Linux box running a 2.6.5 kernel.
>
> Okay, I'm offically confused then. I thought the PID
> was unique among active connections. Then wouldn't
> the
> hash be accessible from multiple processes and not
> just one? Or does the shared library get loaded
> separately for each process? If so, then there is no
> need at all for a hash table, and a simple global
> int
> would do. Maybe the whole thing is just overkill.

Just rewrote it. Trival, like you said. It works
perfectly with just having a single global int. I just
didn't understand the process/thread model inside the
extensional C under Postgresql.

Great!!!! We only have two issues about moving away
from Oracle now: 1) load testing (this shouldn't be a
problem, we currently need about 4TPS, max 10TPS). 2)
Reporting tools.

In the perfect world, a single tool could write fancy
reports versus both PostGres and Oracle. We've yet to
find that tool. New thread maybe?

Shawn

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

pgsql-novice by date:

Previous
From: Shawn Garbett
Date:
Subject: Re: Extending SQL with C, shared library problem
Next
From: Tom Lane
Date:
Subject: Re: Extending SQL with C, shared library problem