Re: RE: [ADMIN] High memory usage [PATCH]

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Dave(at)micro-automation(dot)net
Cc: "'Barry Lind'" <blind(at)xythos(dot)com>, "'PostgreSQL jdbc list'" <pgsql-jdbc(at)postgresql(dot)org>
Subject: Re: RE: [ADMIN] High memory usage [PATCH]
Date: 2001-06-25 14:59:11
Message-ID: 200106251459.f5PExBq05274@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-adminpgsql-jdbcpgsql-patches


Barry, let me back out Dave's change until we can all agree on it, OK?
It is easy to do.

> Barry,
>
> My patch was attempting to maintain some sort of thread safety. I do not
> think the if (df==null) test is thread-safe. It would need to be
> synchronized.
>
> However, as I have mentioned in a couple of previous posts; I'm not sure
> thread-safety is worthwhile. The driver appears to be thread safe in
> that multiple threads can each use different instances of connections,
> and statements, and resultset's however I don't think it is thread safe
> in the sense that multiple threads could use the same instance of the
> above objects. The JDBC guide suggests that the driver s/b threadsafe in
> this sense (multiple threads....same object). The guide suggests that
> one thread may instigate the retrieval of a result set, and another
> would display it.
>
>
> Where this is leading is: What kind of thread safety are we trying to
> achieve?
>
> If it's only one instance per thread then, I would have to agree that
> Barry's patch s/b applied.
>
> P.S.
>
> Is there a formal process within the postgres group for making these
> kind of decisions.
>
> If not I would like to suggest adopting the apache groups +1,-1 voting
> approach.
>
> -----Original Message-----
> From: Barry Lind [mailto:blind(at)xythos(dot)com]
> Sent: June 25, 2001 12:37 AM
> To: pgsql-patches(at)postgresql(dot)org
> Cc: Dave(at)micro-automation(dot)net; 'PostgreSQL jdbc list'
> Subject: Re: [ADMIN] High memory usage [PATCH]
>
> Since this patch got applied before I got around to commenting on it, I
> have submitted a new patch to address my issues with the original patch.
>
> The problem with the patch as applied is that is always creates the
> SimpleDateFormat objects in the constructor of the PreparedStatement
> regardless of whether or not they will ever be used in the
> PreparedStatement. I have reverted back to the old behavior that only
> creates them if necessary in the setDate and setTimestamp methods.
>
> I also removed the close() method. It's only purpose was to free these
> two SimpleDateFormat objects. I think it is much better to leave these
> two objects cached on the thread so that other PreparedStatements can
> use them. (This was the intention of a patch I submitted back in
> February where I was trying to remove as many object creations as
> possible to improve performance. That patch as written needed to get
> pulled because of the problem that SimpleDataFormat objects are not
> thread safe. Peter then added the ThreadLocal code to try to solve the
> performance problem, but introduced the memory leak that originated this
>
> email thread.) I think the cost of at most two SimpleDateFormat objects
>
> being cached on each thead is worth the benefits of less object creation
>
> and subsequent garbage collection.
>
> thanks,
> --Barry
>
>
> Bruce Momjian wrote:
>
> > Patch applied. Thanks.
> >
> >
> >>Here is a patch which inspired by Michael Stephens that should work
> >>
> >>Dave
> >>
> >>
> >>-----Original Message-----
> >>From: pgsql-jdbc-owner(at)postgresql(dot)org
> >>[mailto:pgsql-jdbc-owner(at)postgresql(dot)org] On Behalf Of Gunnar R?nning
> >>Sent: June 22, 2001 10:14 AM
> >>To: Rainer Mager
> >>Cc: Dave Cramer; Bruce Momjian; PostgreSQL jdbc list
> >>Subject: Re: [JDBC] Re: [ADMIN] High memory usage [PATCH]
> >>
> >>* "Rainer Mager" <rmager(at)vgkk(dot)com> wrote:
> >>|
> >>
> >>| Interesting. I wasn't aware of this. If question #2 is answered such
> >>that
> >>| thread safe isn't necessary, then this problem goes away pretty
> >>easily. If
> >>| thread safety is needed then this would have to be rewritten, I can
> >>look
> >>| into doing this if you like.
> >>
> >>Thread safety is required by the spec. Do you have "JDBC API tutorial
> >>and
> >>reference, 2 ed." from Addison Wesley ? This book contains a section
> for
> >>
> >>JDBC driver writers and explains this issue.
> >>
> >>regards,
> >>
> >> Gunnar
> >>
> >>--
> >>Gunnar R?nning - gunnar(at)polygnosis(dot)com
> >>Senior Consultant, Polygnosis AS, http://www.polygnosis.com/
> >>
> >>---------------------------(end of
> broadcast)---------------------------
> >>TIP 1: subscribe and unsubscribe commands go to
> majordomo(at)postgresql(dot)org
> >>
> >>
> >
> > [ Attachment, skipping... ]
> >
> >
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo(at)postgresql(dot)org
>

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

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Barry Lind 2001-06-25 15:39:22 Re: [ADMIN] High memory usage [PATCH]
Previous Message Christof Glaser 2001-06-25 13:54:03 Re: Data Conversion

Browse pgsql-patches by date

  From Date Subject
Next Message Zeugswetter Andreas SB 2001-06-25 15:00:37 AW: AW: AW: [PATCH] Re: Setuid functions
Previous Message Dave Cramer 2001-06-25 12:11:10 RE: [ADMIN] High memory usage [PATCH]

Browse pgsql-jdbc by date

  From Date Subject
Next Message Peter Eisentraut 2001-06-25 15:36:46 Re: Fixing SQLException error codes.
Previous Message Dave Cramer 2001-06-25 12:11:10 RE: [ADMIN] High memory usage [PATCH]