Re: Logging function calls to figure out lo_close log entr
От | Ron Snyder |
---|---|
Тема | Re: Logging function calls to figure out lo_close log entr |
Дата | |
Msg-id | F888C30C3021D411B9DA00B0D0209BE803BB9976@cvo-exchange.cvo.roguewave.com обсуждение исходный текст |
Список | pgsql-jdbc |
The architecture of the java code, or the architecture of the DB? (or the hardware underneath?) I'm not sure which you're asking about. This particular portion of the architecture is just trying to retrieve a gzipped large object (xml text) and display it through a web interface. As far as I'm aware, they're not having any problems from the viewer end other than occasional (sometimes frequent) extremely slow performance. I think we've ruled out DB and machine performance problems, although I have started getting information that leads me to believe that the slow periods are related to the large object entries in my log. There may be a couple different parts within the system that interact with the large object, but I don't know that portion of the system at all. There are a lot of lines of code, but I don't have the numbers. Thanks, -ron > -----Original Message----- > From: Dave Cramer [mailto:Dave@micro-automation.net] > Sent: Wednesday, May 08, 2002 4:08 PM > To: Ron Snyder > Cc: 'pgsql-jdbc@postgresql.org' > Subject: RE: [JDBC] Logging function calls to figure out > lo_close log entr ies? > > > Ron, > > I'm not sure how you would actually go about doing this, the > driver s/b > throwing an exception at the invalid large object error anyway. > > What is the system architecture, I am presuming this is a fairly large > system? > > Dave > On Wed, 2002-05-08 at 18:54, Ron Snyder wrote: > > > > > > > That does make it tough ;) > > > On Wed, 2002-05-08 at 16:00, Ron Snyder wrote: > > > > > Can you send the relevant java code as well > > > > > > > > That's part of the problem -- we don't know what code is > > > doing it, and we're > > > > trying to narrow it down. > > > > > > > > Hmm, what if I took a really aggressive approach (with the > developers > > agreement of course) and told the backend to emit some > message that could > > cause the jdbc client to spit out an exception-- that would tell the > > developers exactly where things were going wrong, wouldn't it? > > > > If possible it would just give the client some message, but > I suspect that > > I'm actually going to have to exit() in order to force that > exception-- any > > ideas how to force one backend to exit without possibly > messing up the > > shared memory area? > > > > -ron > > > > > >
В списке pgsql-jdbc по дате отправления: