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

Re: LargeObject API and OIDs

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Christian Niles <christian(at)unit12(dot)net>
Cc: pgsql-jdbc(at)postgresql(dot)org
Subject: Re: LargeObject API and OIDs
Date: 2004-10-24 20:26:54
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-jdbc
Christian Niles <christian(at)unit12(dot)net> writes:
> 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?

No; instead you'd get a failure during lo_create:

	/* Check for duplicate (shouldn't happen) */
	if (LargeObjectExists(file_oid))
		elog(ERROR, "large object %u already exists", file_oid);

You could deal with this by retrying lo_create until it succeeds.
However, if you are expecting more than a few tens of millions of
objects, you probably don't want to go this route because the
probability of collision will be too high; you could spend a long time
iterating to find a free OID.  Something involving a bigint identifier
would work better.

> Also, would 
> the number of large objects available be limited by other database 
> objects that use OIDs?

No.  Although we use just a single OID sequence generator, each
different kind of system object has a separate unique index (or other
enforcement mechanism), so it doesn't really matter if, say, an OID in
use for a large object is also in use for a table.

			regards, tom lane

In response to


pgsql-jdbc by date

Next:From: Euler Taveira de OliveiraDate: 2004-10-25 02:30:58
Subject: Translation update: pt_BR
Previous:From: Kris JurkaDate: 2004-10-24 20:00:28
Subject: Re: Problem with fixed length fields.

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