Skip site navigation (1) Skip section navigation (2)

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

From: "Dave Cramer" <Dave(at)micro-automation(dot)net>
To: "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>, "Rainer Mager" <rmager(at)vgkk(dot)com>
Cc: "PostgreSQL jdbc list" <pgsql-jdbc(at)postgresql(dot)org>
Subject: Re: Re: [ADMIN] High memory usage [PATCH]
Date: 2001-06-22 00:33:59
Message-ID: 018601c0fab3$082dc080$0201a8c0@INSPIRON (view raw or flat)
Thread:
Lists: pgsql-adminpgsql-jdbcpgsql-patches
my two cents worth...

1) what is the problem that this is trying to solve, I assume from the
subject that it is some sort of high memory usage?
2) I am trying to understand how a statement would ever be used by more than
one thread at a time? I would think that it would be impossible to share
statements across threads.
3) The double locking method used is alledgedly unsafe on SMP machines
http://www.javaworld.com/javaworld/jw-02-2001/jw-0209-double_p.html.


Dave




----- Original Message -----
From: "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: "Rainer Mager" <rmager(at)vgkk(dot)com>
Cc: "PostgreSQL jdbc list" <pgsql-jdbc(at)postgresql(dot)org>; "PostgreSQL-patches"
<pgsql-patches(at)postgresql(dot)org>
Sent: Thursday, June 21, 2001 6:23 PM
Subject: [JDBC] Re: [ADMIN] High memory usage [PATCH]


>
> JDBC folks, can you comment on this patch?  Thanks.
>
>
> > Attached is my patch to the official 7.1.2 PreparedStatement.java class.
> > This seems to work quite well for me in a test case. To try to reproduce
the
> > seen problem I will need to test all night. I'll report tomorrow.
> >
> > BTW, this is my first attempt at making a unified diff so I might have
done
> > something wrong. If this diff doesn't apply please tell me.
> >
> > --Rainer
> >
> > > -----Original Message-----
> > > From: pgsql-admin-owner(at)postgresql(dot)org
> > > [mailto:pgsql-admin-owner(at)postgresql(dot)org]On Behalf Of Rainer Mager
> > > Sent: Wednesday, June 20, 2001 9:08 AM
> > > To: Tom Lane
> > > Cc: PostgreSQL Admin
> > > Subject: RE: [ADMIN] High memory usage
> > >
> > >
> > > I'll work on a patch but if someone has already done this I would be
> > > grateful.
>
> [ 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
>


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


> --- PreparedStatement.java Sat Feb 17 01:45:00 2001
> +++ PreparedStatement.java.new Wed Jun 20 12:34:57 2001
> @@ -39,10 +39,12 @@
>          // Some performance caches
>          private StringBuffer sbuf = new StringBuffer();
>
> -        // We use ThreadLocal for SimpleDateFormat's because they are not
that
> -        // thread safe, so each calling thread has its own object.
> -        private ThreadLocal tl_df   = new ThreadLocal(); // setDate()
SimpleDateFormat
> -        private ThreadLocal tl_tsdf = new ThreadLocal(); //
setTimestamp() SimpleDateFormat
> + // Because SimpleDateFormat is not thread safe we create one for each
> + // PreparedStatemnt here AND synchronize on it for each usage.
> + // We can NOT use ThreadLocal because they are not freed until the
thread
> + // completes. This would be a memory leak for long running threads.
> + private SimpleDateFormat df = null;
> + private SimpleDateFormat tsdf = null;
>
>   /**
>   * Constructor for the PreparedStatement class.
> @@ -90,9 +92,6 @@
>           * New in 7.1 - overides Statement.close() to dispose of a few
local objects
>           */
>          public void close() throws SQLException {
> -          // free the ThreadLocal caches
> -          tl_df.set(null);
> -
>            super.close();
>          }
>
> @@ -332,14 +331,18 @@
>   */
>   public void setDate(int parameterIndex, java.sql.Date x) throws
SQLException
>   {
> -          SimpleDateFormat df = (SimpleDateFormat) tl_df.get();
> -          if(df==null) {
> + // The df DateFormat is initialized here to delay creation until needed.
> + if( df == null ) {
> + synchronized( this ) {
> + if( df == null ) {
>              df = new SimpleDateFormat("''yyyy-MM-dd''");
> -            tl_df.set(df);
> + }
> + }
>            }
>
> -   set(parameterIndex, df.format(x));
> -
> + // We must synchronize here because SimpleDateFormat is not thread safe.
> + synchronized( df ) {
> + set( parameterIndex, df.format(x) );
>     // The above is how the date should be handled.
>     //
>     // However, in JDK's prior to 1.1.6 (confirmed with the
> @@ -351,6 +354,7 @@
>     //
>     //set(parameterIndex, df.format(new
java.util.Date(x.getTime()+86400000)));
>   }
> + }
>
>   /**
>   * Set a parameter to a java.sql.Time value.  The driver converts
> @@ -375,17 +379,22 @@
>   */
>   public void setTimestamp(int parameterIndex, Timestamp x) throws
SQLException
>          {
> -          SimpleDateFormat df = (SimpleDateFormat) tl_tsdf.get();
> -          if(df==null) {
> -            df = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
> -            tl_tsdf.set(df);
> + // The tsdf DateFormat is initialized here to delay creation until
needed.
> + if( tsdf == null ) {
> + synchronized( this ) {
> + if( tsdf == null ) {
> + tsdf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
> + tsdf.setTimeZone(TimeZone.getTimeZone("GMT"));
> + }
> + }
>            }
> -          df.setTimeZone(TimeZone.getTimeZone("GMT"));
>
> + // We must synchronize here because SimpleDateFormat is not thread safe.
> + synchronized( tsdf ) {
>            // Use the shared StringBuffer
>            synchronized(sbuf) {
>              sbuf.setLength(0);
> -
sbuf.append("'").append(df.format(x)).append('.').append(x.getNanos()/100000
00).append("+00'");
> +
sbuf.append("'").append(tsdf.format(x)).append('.').append(x.getNanos()/1000
0000).append("+00'");
>              set(parameterIndex, sbuf.toString());
>            }
>
> @@ -393,6 +402,7 @@
>            // to be identical. Pays to read the docs ;-)
>            //set(parameterIndex,"'"+x.toString()+"'");
>   }
> + }
>
>   /**
>   * When a very large ASCII value is input to a LONGVARCHAR parameter,
>


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


>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/users-lounge/docs/faq.html
>


In response to

Responses

pgsql-admin by date

Next:From: Yasuo OhgakiDate: 2001-06-22 02:31:08
Subject: Re: Gradual increase in CPU utilization by postmaster
Previous:From: Gerard MasonDate: 2001-06-21 23:43:21
Subject: Re: pg_dump dumps views as tables???

pgsql-patches by date

Next:From: Marko KreenDate: 2001-06-22 00:36:40
Subject: Re: use GUC for cmdline
Previous:From: Tom LaneDate: 2001-06-21 23:50:44
Subject: Re: use GUC for cmdline

pgsql-jdbc by date

Next:From: Rainer MagerDate: 2001-06-22 04:56:17
Subject: RE: Re: [ADMIN] High memory usage [PATCH]
Previous:From: Bruce MomjianDate: 2001-06-21 22:23:58
Subject: Re: [ADMIN] High memory usage [PATCH]

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group