Re: Relation 'pg_largeobject' does not exist

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Brandon Keepers <bkeepers(at)gmail(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Relation 'pg_largeobject' does not exist
Date: 2006-03-14 02:12:55
Message-ID: 12139.1142302375@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Brandon Keepers <bkeepers(at)gmail(dot)com> writes:
> Thanks for your quick response! I had actually just been trying that
> (with 7.1) and came across another error:

> NOTICE: ShmemAlloc: out of memory
> NOTICE: LockAcquire: xid table corrupted
> dumpBlobs(): Could not open large object. Explanation from backend:
> 'ERROR: LockRelation: LockAcquire failed

Ugh :-( How many blobs have you got, thousands? 7.0 stores each blob
as a separate table, and I'll bet it is running out of lock table space
to hold a lock on each one. My recollection is that we converted blob
storage to a single pg_largeobject table precisely because of that
problem.

What you'll need to do to get around this is to export each blob in a
separate transaction (or at least no more than a thousand or so blobs
per transaction). It looks like pg_dumplo might be easier to hack to do
things that way --- like pg_dump, it puts a BEGIN/COMMIT around the
whole run, but it's a smaller program and easier to move those commands
in.

Another possibility is to increase the lock table size, but that would
probably require recompiling the 7.0 backend. If you're lucky,
increasing max_connections to the largest value the backend will support
will be enough. If you've got many thousands of blobs there's no hope
there, but if it's just a few thousand this is worth a try before you go
hacking code.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message CSN 2006-03-14 02:24:05 in text field
Previous Message Brandon Keepers 2006-03-14 01:43:49 Re: Relation 'pg_largeobject' does not exist