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