Re: 64-bit API for large object - Mailing list pgsql-hackers

From Tatsuo Ishii
Subject Re: 64-bit API for large object
Date
Msg-id 20120827.082530.238331286109513911.t-ishii@sraoss.co.jp
Whole thread Raw
In response to 64-bit API for large object  (Tatsuo Ishii <ishii@postgresql.org>)
Responses Re: 64-bit API for large object
List pgsql-hackers
> Hi,
> 
> I found this in the TODO list:
> 
>   Add API for 64-bit large object access 
> 
> If this is a still valid TODO item and nobody is working on this, I
> would like to work in this.

Here are the list of functions think we need to change.

1) Frontend lo_* libpq functions(fe-lobj.c)

lo_initialize() need to get backend 64-bit large object handling
function's oid, namely lo_lseek64, lo_tell64, lo_truncate64, loread64,
lowrite64(explained later). If they are not available, use older
32-bit backend functions.

BTW, currently lo_initialize() throws an error if one of oids are not
avilable. I doubt we do the same way for 64-bit functions since this
will make 9.3 libpq unable to access large objects stored in pre-9.2
PostgreSQL servers.

2) Bakend lo_* functions (be-fsstubs.c)

Add lo_lseek64, lo_tell64, lo_truncate64, loread64 and lowrite64 so
that they can handle 64-bit seek position and data lenghth.

3) Backend inv_api.c functions

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.

Comments, suggestions?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: 9.2RC1 wraps this Thursday ...
Next
From: Tatsuo Ishii
Date:
Subject: Incorrect comment in fe-lobj.c