losing my large objects with Postgresql 8.1.4 and 8.1.5 - Mailing list pgsql-general

From Eric Davies
Subject losing my large objects with Postgresql 8.1.4 and 8.1.5
Date
Msg-id 7.0.1.0.0.20070105151122.01e95508@barrodale.com
Whole thread Raw
Responses Re: losing my large objects with Postgresql 8.1.4 and 8.1.5
List pgsql-general

Some of  my custom server functions/data types that work correctly under Postgresql 8.0.1 are having trouble with lost large objects under Postgresql 8.1.4 and Postgresql 8.1.5, but only in particular usages. I'm hoping somebody familiar with the changes made to Postgresql  since 8.0.X can suggest what might be happening.

Details:
I have a datatype for storing large blocks of data. Because a block of data may be multi gigabytes in size, I can't rely on the toaster mechanism. Instead, each instance of my datatype contains a key to another table that contains a list of oids for large objects (each containing a portion of the block).

My functions are written in C using the SPI interface. One of the functions creates an instance of the datatype, and another one converts the datatype to text.

When I execute the following sequence of commands:
         select   MyTypeToText( BuildMyType('asdf'));
I get the following error
         ERROR:  large object 33016 does not exist
\lo_list (in psql) doesn't show any new large objects.

However, when I execute the following sequence of commands:
         create table smith( a MyType);
         insert into smith select BuildMyType('asdf');
         select MyTypeToText(a) from smith;
the contents of the MyType object are displayed correctly, no error messages.
\lo_list shows an additional large object.

I have stepped through both the BuildMyType function and the MyTypeToText function and seen that the
lob id that BuildMyType is using is the same one that MyTypeToText is trying to use in the problem case.

I tried producing a reduced version of the MyType code to demonstrate the problem but unfortunately it works perfectly.

Can anybody suggest what could cause this type of behavior?

Thank you,

**********************************************
Eric Davies, M.Sc.
Barrodale Computing Services Ltd.
Tel: (250) 472-4372 Fax: (250) 472-4373
Web: http://www.barrodale.com
Email: eric@barrodale.com
**********************************************
Mailing Address:
P.O. Box 3075 STN CSC
Victoria BC Canada V8W 3W2

Shipping Address:
Hut R, McKenzie Avenue
University of Victoria
Victoria BC Canada V8W 3W2
**********************************************


pgsql-general by date:

Previous
From: "Thomas F. O'Connell"
Date:
Subject: Re: upgrading and pg_restore versions
Next
From: Reid Thompson
Date:
Subject: Re: GUI tool that can reverse engineering schemas