On 20/09/10 18:12, Kevin Grittner wrote:
On the Serializable Snapshot Isolation thread, Heikki pointed out a collection of objects in an HTAB which didn't really need its key on VirtualTransactionId, but there isn't really any other useful key, either. One of these objects may live and die, seeing use from multiple processes, without ever getting a TransactionId assigned; and it needs to be in a collection in shared memory the whole time. This suggests to me that some sort of list would be better.
In the SSI patch, you'd also need a way to insert an existing struct into a hash table. You currently work around that by using a hash element that contains only the hash key, and a pointer to the SERIALIZABLEXACT struct. It isn't too bad I guess, but I find it a bit confusing.
SHM_QUEUE objects provide the infrastructure for maintaining a shared memory linked list, but they don't do anything about the allocation and release of the space for the objects. So it occurs to me that I'm using an HTAB for this collection because it provides the infrastructure for managing the memory for the collection, rather than because I need hash lookup. :-( It works, but that hardly seems optimal.
Have I missed something we already have which could meet that need?
Well, we generally try to avoid dynamic structures in shared memory, because shared memory can't be resized. So, you'd typically use an array with a fixed number of elements. One could even argue that we specifically *don't* want to have the kind of infrastructure you propose, to discourage people from writing patches that need dynamic shmem structures.
Any chance of collapsing together entries of already-committed transactions in the SSI patch, to put an upper limit on the number of shmem list entries needed? If you can do that, then a simple array allocated at postmaster startup will do fine.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
