-----Original Message-----
From: Peter T Mount <psqlhack@maidast.demon.co.uk>
To: Maurice Gittens <mgittens@gits.nl>
Cc: PostgreSQL-development <hackers@postgreSQL.org>
Date: maandag 9 maart 1998 3:34
Subject: Re: [HACKERS] newoid in invapi.c
>> This might lead the large object implementation to confuse
>> large object relations with other relations.
>>
>> According to me this is a bug. I'm I right?
>
>Yes, and no. LargeObjects are supposed to run within a transaction (if you
>don't then some fun things happen), and (someone correct me if I'm wrong)
>if newoid() is called from within the transaction, it is safe?
>
I see no evidence in the code that suggests that it is safe in transactions.
The GetNewObjectIdBlock() function which generates the OID blocks _does_
acquire a spinlock before it generates a new block of oids so usually all
will be well.
But sometimes ((a chance of <usercount>/32) when there <usercount> active
users
for the same db) the newoid might have a quite different value than
fileoid+1.
Again I see no evidence in the code that it is safe in transactions. I only
see evidence that it will _usually_ work.
Actually I wonder how it could be efficiently made safe within transactions
given
that the oids generated are guaranteed to be unique within an
_entire_ postgres installation. This would seem to imply that, effectively,
only one transaction would be possible at the same time in an entire
postgresql database.
My current strategy to solve this problem involves the use of a new
system catalog which I call pg_large_object. This catalog contains
information about each large object in the system.
Currently the information maintained is:
- identification of heap and index relations used by the large_object
- the size of the large object
- information about the type of the large object.
I still need to figure out how to create a new _unique_ index on a system
catalog using information in the indexing.h file.
Given an oid this table allow us to determine if it is a valid large object.
I think this is necesary (to be able to maintain referential integrity) if
we're ever
going to have large object type.
Similarly I have defined a table pg_tuple which allows one to
determine if a given oid is a valid tuple.
This together with some other minor changes allows some cool
object oriented features for postgresql.
Fancy the idea of persistent Java object which live in postgresql databases?
Anyway if it all works as expected I'll submit some patches.
Thanks,
Maurice