Re: Re: libpq++ - Mailing list pgsql-interfaces

From Bruce Momjian
Subject Re: Re: libpq++
Date
Msg-id 200105031915.f43JFpf12056@candle.pha.pa.us
Whole thread Raw
In response to Re: Re: libpq++  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-interfaces
> Justin Banks <justinb@mr-boo.com> writes:
> > As one would have expected, I've found a problem. The c++ std. says that
> > Automatic objects are not destroyed as a result of calling exit(), and so, a
> > automatic PgDatabase in main() (or most anywhere, actually), would not have
> > it's destructor called during an exit(), thereby leaving junk shm. segments
> > around.
> 
> Unless your kernel is broken, application exit will cause the backend
> connection to be closed, whereupon the backend will exit gracefully.
> I see nothing to worry about here.
> 
> I'm not sure where you got this notion that clients get to touch any
> of Postgres' shared memory ;-) but they don't.

I think he is creating his own shared memory area:

---------------------------------------------------------------------------

What I'd like to have happen is for a total of one connection to the
database to be made, and have all these objects share that connection
transparently. I made this happen by using a shared memory segment to
store the connection pointer. Here's the diff. It doesn't seem to break
anything, but then again, my coverage is rather limited at this point.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


pgsql-interfaces by date:

Previous
From: Tom Lane
Date:
Subject: Re: Null values where they should not be...HELP Please!!
Next
From: Tom Lane
Date:
Subject: Re: Null values where they should not be...HELP Please!!