LargeObject API and OIDs

From: Christian Niles <christian(at)unit12(dot)net>
To: pgsql-jdbc(at)postgresql(dot)org
Subject: LargeObject API and OIDs
Date: 2004-10-24 17:34:15
Message-ID: ED2AAA08-25E2-11D9-AD96-000A9590B78E@unit12.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

I'm using PostgreSQL as the backend for a versioning content store, and
after reading the JDBC docs, I'm planning on using the LargeObject API
to store the actual data. I noticed that large objects are referenced
using unsigned 4-byte integers, which for practical purposes should be
fine, assuming there's no chance for data corruption if the number is
exceeded.

However, since a versioning system will have a higher number of entries
compared to a normal storage system, I'm curious if there's any chance
for data corruption in the case that the DB runs out of OIDs. Ideally,
the database would raise an exception, and leave the existing data
untouched. From what I've read in the documentation, OIDs aren't
guaranteed to be unique, and may cycle. In this case, would the first
large object after the limit overwrite the first object? Also, would
the number of large objects available be limited by other database
objects that use OIDs?

The majority of the content stored in the system will be in small
files, with the exception of some images, PDFs and so forth. So, if
there is a chance for data corruption, I may implement a scheme were
only files above some threshold are stored using large objects, and all
others are stored in a bytea column. The JDBC docs mention the
performance problems with large bytea values, but are there any
implementation factors that might affect the threshold I choose?

I apologize that this isn't specifically JDBC related, but since I'm
using JDBC for all of this, I thought I'd ask here first.

best,
christian.

Responses

Browse pgsql-jdbc by date

  From Date Subject
Next Message Kris Jurka 2004-10-24 19:36:38 Re: Translation updates: ru.po
Previous Message Tom Lane 2004-10-23 21:54:45 Re: Problem with fixed length fields.