Re: [HACKERS] tables >2GB
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] tables >2GB |
Дата | |
Msg-id | 199803201729.MAA08356@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] tables >2GB (Tom Ivar Helbekkmo <tih@Hamartun.Priv.NO>) |
Ответы |
Re: [HACKERS] tables >2GB
|
Список | 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 по дате отправления: