64-bit API for large objects

From: Mark Dilger <pgsql(at)markdilger(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: 64-bit API for large objects
Date: 2005-09-18 16:13:00
Message-ID: 432D920C.5030709@markdilger.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

My company has written a 64-bit large object API, extending the postgresql
server to be able to read/write/seek/tell/open/close objects larger than 2GB.
If the hackers community considers this valuable, we will submit the changes
back for the rest of the community to share.

From one of my programmers, Jeremy Drake:

I tested this out on my box with a 4gb dvd iso image, and it appears to
work correctly. The test code I found for large object things does not
really seem to exercise the api very well though. And the regression
tests do not seem to even touch large objects (they all still pass after
this change).

Mark, can you take a look at this and make sure I haven't broken anything
too obviously?

I wrote it into the same file as the large object code, since that file
has some static stuff for caching things which I would like to share. I
opted to add new functions tell64 and seek64 rather than changing the
existing ones for backwards compatibility. I plugged them into the
pg_proc catalog, but everything in that file has an explicit OID, and I do
not feel comfortable (yet) grabbing up OIDs for stuff. So I set them to
an OID of zero, which means the scripts will assign it one which is not
used (in the range 10000-something). Since the convention is that such
functions have explicit assigned OIDs, it would probably be required to
get real ones if this were ever to be submitted back. Also, in the libpq
stuff, at the moment I have it fail if it cannot find the seek64 or tell64
functions. It may be best to have it work as long as you don't try to
call them, in order to preserve backwards compatibility with other server
versions.

If you think this is a reasonable patch, it might be nice to send it to
them, be a good neighbor and all that...

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim C. Nasby 2005-09-18 16:33:54 Re: Spinlocks, yet again: analysis and proposed patches
Previous Message Reini Urban 2005-09-18 11:07:51 Re: [pgsql-hackers-win32] Time to close pgsql-cygwin?