[GRASS5] Re: [winGRASS] ARG_MAX and parser.c
Eric G. Miller
egm2 at jps.net
Wed Aug 8 23:04:53 EDT 2001
On Wed, Aug 08, 2001 at 08:39:04PM +0100, Glynn Clements wrote:
>
> Andreas Lange wrote:
>
> > There is no ARG_MAX in src/libes/gis/parser.c and there will never be
> > one.
> >
> > I just added some ifdefs to
> > src.garden/grass.postgresql/d.site.pg/main.c, as this did not compile on
> > cygwin.
>
> Er, why is that file using ARG_MAX anyway?
I'll take credit for that. It was statically defined as 1024 before. I
can't remember why I used it... I was focused on fixing up the calls to
parser code...
>
> 1. AFAICT, if the statement is longer than ARG_MAX, the code will
> simply read the first ARG_MAX bytes of the statement then try to
> execute that as an SQL query.
>
> 2. The buffer which is being limited to ARG_MAX bytes (SQL_stmt) is
> being passed to PQexec(); so why is the limit ARG_MAX bytes? The libpq
> documentation (from PostgreSQL 6.5.3) says:
>
> Caveats
>
> The query buffer is 8192 bytes long, and queries over that length
> will be rejected.
>
> However, I don't see that simply truncating the query helps at all. I
> suspect it would be better to just pass the entire query and let
> PQexec() reject it.
Trivial changes would do this.
In "main.c":
Eliminate ARG_MAX and <limits.h>.
Change for() loop reading file to:
for (stmt_sz = 1024; ; stmt_sz += 1024) {...}
Course, someone could specify /dev/random and exhaust system memory, but
presumably we have trusted users ;)
--
Eric G. Miller <egm2 at jps.net>
More information about the grass-dev
mailing list