Re: 64-bit API for large object
От | Nozomi Anzai |
---|---|
Тема | Re: 64-bit API for large object |
Дата | |
Msg-id | 20120921103431.a5f62e042a37eacfd99fb7ac@sraoss.co.jp обсуждение исходный текст |
Ответ на | Re: 64-bit API for large object (Kohei KaiGai <kaigai@kaigai.gr.jp>) |
Список | pgsql-hackers |
> > 3) Backend inv_api.c functions(Nozomi Anzai) > > > > No need to add new functions. Just extend them to handle 64-bit data. > > > > BTW , what will happen if older 32-bit libpq accesses large objects > > over 2GB? > > > > lo_read and lo_write: they can read or write lobjs using 32-bit API as > > long as requested read/write data length is smaller than 2GB. So I > > think we can safely allow them to access over 2GB lobjs. > > > > lo_lseek: again as long as requested offset is smaller than 2GB, there > > would be no problem. > > > > lo_tell:if current seek position is beyond 2GB, returns an error. > > > Even though iteration of lo_lseek() may move the offset to 4TB, it also > makes unavailable to use lo_tell() to obtain the current offset, so I think > it is reasonable behavior. > > However, error code is not an appropriate one. > > + if (INT_MAX < offset) > + { > + ereport(ERROR, > + (errcode(ERRCODE_UNDEFINED_OBJECT), > + errmsg("invalid large-object > descriptor: %d", fd))); > + PG_RETURN_INT32(-1); > + } > > According to the manpage of lseek(2) > EOVERFLOW > The resulting file offset cannot be represented in an off_t. > > Please add a new error code such as ERRCODE_BLOB_OFFSET_OVERFLOW. Agreed. -- Nozomi Anzai SRA OSS, Inc. Japan
В списке pgsql-hackers по дате отправления: