Return-Path: mao
Received: by postgres.Berkeley.EDU (5.61/1.29)
	id AA01133; Sat, 20 Feb 93 16:46:57 -0800
Message-Id: <9302210046.AA01133@postgres.Berkeley.EDU>
From: <mao@postgres.berkeley.edu>
Subject: Re: rewriting to Large Objects
To: postgres@postgres.berkeley.edu
Sender: pg_adm@postgres.berkeley.edu
In-Reply-To: Your message of Sat, 20 Feb 93 16:14:00 PST.
             <9302210014.AA00986@postgres.Berkeley.EDU> 
Date: Sat, 20 Feb 93 16:47:19 PST

In message <9302210014.AA00986@postgres.Berkeley.EDU> you write:

> p_create works fine, but the combination of p_open
> and p_write does not work as I expected. It seems that
> when opening an object the location pointer is positioned
> at the end of the existing data. I did an lseek(fd,0,L_SET)
> and it seems to work, but data is not completely overwritten.

the fact that you have to p_lseek(fd, 0, L_SET) after open is a known
bug in the 4.0.1 implementation; it's fixed in 4.1.

> The objects I'm using for my tests are ascii text, and it
> seems that if a space is in the new data, the old character
> is not overwritten. E.g. if an object initially contains
> 	'ABCDEABCDEABCDE'
> and I try to replace it with
> 	'12345     12345'
> the new object is
> 	'12345ABCDE12345'

can you send me a sample program that demonstrates this behavior?

> Occasionally (I haven't observed a pattern) postgres crashes
> with the msg:
> 
> Error: Unexpected identifier: ?.~~~

any more detailed information you could give would be helpful.  this message
means that the backend crashed, and left a core file in the data/base/<dbname>
directory.  could you extract a backtrace and send it to us the next time
you see this behavior?

> Also, how can space used by large objects be freed?

in 4.0.1, due to a bug in prm, it isn't freed automatically.  this is also
fixed in the next release.
					mike