Re: Logging function calls to figure out lo_close log entr - Mailing list pgsql-jdbc

From Ron Snyder
Subject Re: Logging function calls to figure out lo_close log entr
Date
Msg-id F888C30C3021D411B9DA00B0D0209BE803BB9976@cvo-exchange.cvo.roguewave.com
Whole thread Raw
List 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 by date:

Previous
From: Dave Cramer
Date:
Subject: Re: Logging function calls to figure out lo_close log entr
Next
From: senthil kumar
Date:
Subject: servlet problem