Received: from sss.pgh.pa.us (sss.pgh.pa.us [216.151.103.158]) by postgresql.org (8.11.3/8.11.1) with ESMTP id f43JEaA59949 for ; Thu, 3 May 2001 15:14:38 -0400 (EDT) (envelope-from tgl@sss.pgh.pa.us) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.11.3/8.11.3) with ESMTP id f43JD1R29890; Thu, 3 May 2001 15:13:01 -0400 (EDT) To: justinb@mr-boo.com cc: Bruce Momjian , justinb@tricord.com, PostgreSQL-interfaces Subject: Re: Re: libpq++ In-reply-to: <15085.24280.868910.556829@dervish.mr-boo.com> References: <15084.18414.123450.642118@idoru.tricord.com> <200104292004.f3TK4nf21949@candle.pha.pa.us> <15085.24280.868910.556829@dervish.mr-boo.com> Comments: In-reply-to Justin Banks message dated "Mon, 30 Apr 2001 07:53:02 -0500" Date: Thu, 03 May 2001 15:13:00 -0400 Message-ID: <29887.988917180@sss.pgh.pa.us> From: Tom Lane X-Archive-Number: 200105/12 X-Sequence-Number: 1538 Justin Banks 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. regards, tom lane