Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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

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


pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group