Re: [HACKERS] tables >2GB - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: [HACKERS] tables >2GB
Date
Msg-id 199803201729.MAA08356@candle.pha.pa.us
Whole thread Raw
In response to Re: [HACKERS] tables >2GB  (Tom Ivar Helbekkmo <tih@Hamartun.Priv.NO>)
Responses Re: [HACKERS] tables >2GB
List pgsql-hackers
>
> * Bruce Momjian
> |
> | Well, BSD/OS goes over 2gig, but the postgreSQL code uses lseek, which
> | returns long, so even though I can handle larger files, the lseek()
> | can't because long is 32-bits.
>
> Are you sure?  In NetBSD, lseek() is declared to return an off_t,
> which again is defined to be a 64bit quantity.  I would assume that
> BSD/OS did it the same way -- in fact, I'd be surprised if not.

Oops, you are right:

    typedef quad_t          off_t;

I thought they added fgetpos() only for 64-bit quantities, and did not
change the return value of lseek.  However:

    sys/types.h:76: typedef quad_t          off_t;          /* file offset*/

so you are right, but our code:

    fd.c:110:       long            seekPos;
    fd.c:263:       fileP->seekPos = (long) lseek(fileP->fd, 0L, SEEK_CUR);

so it still will not work because the code is not defining seekPos as
off_t.  We need to get this code cleaned up/fixed.

How could they make such a mistake and assume it is a long, unless this
thing gets passed around in the backend, and they don't want to
reference off_t all over the place?  That code needs cleanup.

--
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] psql nested queries with 2000+ records
Next
From: "Maurice Gittens"
Date:
Subject: Re: [HACKERS] Re: Buffer overruns with the Electric Fence debugging library (Solved?)