Thread: data volume resizing and large objects

Hello All

I recently ran out of disk space on the volume hosting my default tablespace.  As it turned out, the sysad didnt allocate all of the disk to the volume when he installed it, so he resized the volume and restarted the database.  The server came up fine so I assumed all was well ( the server would not start before the resize ), however now when i get failures whenever I try to insert lobs via my application. 

My application is written in perl and uses DBD::Pg and DBI to access the database.  The failure occurs when i attempt to call lo_creat:

     $dbh->func($mode, 'lo_creat');

lo_creat fails with:
    
     ERROR: large object <oid> already exists

This leads me to believe that my database lost its list of existing lob oids and is experiencing collisions but I am not sure where to go from here.  I could really use some additional insight into what is happening here and perhaps some direction in how to remedy the problem.

TIA

-bill

"beer@cmu.edu" <beer@cmu.edu> writes:
> lo_creat fails with:
>      ERROR: large object <oid> already exists

Well, does it?

What PG version is this?  I'm suspicious that it's pre-8.1 and the
problem is that your OID counter has wrapped around to a region that
is already pretty densely populated with large objects.  8.1 and up
are able to pick unused OIDs but earlier versions just fail on
collisions.

            regards, tom lane

Tom

You hit the nail on the head actually! Further delving into the issue revealed that but I hadnt had a chance to post.

We recently used copy to put some lobs back into the database, about 70k of them.  All of these lobs were assigned sequential oids incremented by 1.  We then wrapped around and ended up in that block of oids again.

The irony of all of this is we have been trying to migrate to 8.1 for months now but have not been able to do so due to infrastructure issues beyond our control.

Is there anyway to force 8.0 to start at a specific value?  That would at least get us back up and running.

Thanks

-bill

"beer@cmu.edu" <beer@cmu.edu> writes:
> Is there anyway to force 8.0 to start at a specific value?  That would at
> least get us back up and running.

You're in luck: 8.0's pg_resetxlog has the -o switch, so just shut down
(cleanly), use pg_resetxlog to put the OID counter where you want it,
restart.

            regards, tom lane

beer@cmu.edu wrote:

> Is there anyway to force 8.0 to start at a specific value?  That would at
> least get us back up and running.

Stop the system (cleanly) and use pg_resetxlog -o.

--
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Thank you both!!  That got me back up and running ( for now ).  Hopefully this will give me enough enough time to finish the migration next week.

Thanks again!!