Re: [HACKERS] Disk block size issues.

On Fri, 9 Jan 1998, Bruce Momjian wrote:

> > > This is an interesting point.  While we can compute most of the changes
> > > at compile time, we will have to communicate with clients that were
> > > compiled with different max limits.
> > >
> > > I recommend we increase the max client buffer size to what we believe is
> > > the largest block size anyone would ever reasonably choose.  That way,
> > > all can communicate.  I recommend you contact Peter Mount for JDBC,
> > > Openlink for ODBC, and all the other client maintainers and let them
> > > know the changes will be in 6.3 so they can be ready with new version
> > > when 6.3 starts beta on February 1.

I'll be ready :-)

> > So the buffer size will be defined in one place also that they should all
> > reference when compiling or running?  In include/config.h I assume?
>
> Yes, in config.h, and let's call it PG... so it is clear, and everything
> can key off of that.
>
> >
> > This could be difficult for the ODBC and JDBC drivers to determine
> > automagically since they are usually compiled on different systems that
> > the postgres src.

Not necesarily for JDBC. Because of it's nature, there is no real reason
why we can't even include it precompiled with the source - the same jar
file runs on any platform.

Infact, this does bring up the same problem we were discussing about
earlier, where we were thinking about changing the protocol on startup. If
that change occurs, then this value is an ideal candidate to add to the
startup packet.

> I think they will need to handle the maximum size someone could ever
> choose.  Let's face it, 32k or 64k is not too much to ask for a buffer.
> I just hope there are not too many of them.  I only see it in one place
> in libpq.  The others are malloc'ed based on how big the result is when
> it comes back from the socket.
>
> I recommend we add a test in config.h to make sure they do not set the
> max size greater than some predefined limit, and mention why we test
> there (for clients).  The interface/* files will not use the backend
> block size, but will use another config.h define called PGMAXBLCKSZ, or
> something like that, so they can interoperate will all backends.

Slight problem with JDBC (or Java in general), in that we don't use .h
files, so settings in config.h are useless to us. So far, certain
constants have been duplicated in the source.

I was thinking of possibly adding a couple of functions to the backend, to
allow us to get certain details about the backend, which is needed for
certain DatabaseMetaData methods. Perhaps adding PGMAXBLCKSZ to that may
get round the problem.

--
Peter T Mount  petermount@earthling.net or pmount@maidast.demon.co.uk
Main Homepage: http://www.demon.co.uk/finder
Work Homepage: http://www.maidstone.gov.uk Work EMail: peter@maidstone.gov.uk