I wrote:
> Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> wrote:
>
>> ISTM you never search the SerializableXactHash table using a hash
>> key, except the one call in CheckForSerializableConflictOut, but
>> there you already have a pointer to the SERIALIZABLEXACT struct.
>> You only re-find it to make sure it hasn't gone away while you
>> trade the shared lock for an exclusive one. If we find another
>> way to ensure that, ISTM we don't need SerializableXactHash at
>> all. My first thought was to forget about VirtualTransactionId
>> and use TransactionId directly as the hash key for
>> SERIALIZABLEXACT. The problem is that a transaction doesn't have
>> a transaction ID when RegisterSerializableTransaction is called.
>> We could leave the TransactionId blank and only add the
>> SERIALIZABLEXACT struct to the hash table when an XID is
>> assigned, but there's no provision to insert an existing struct
>> to a hash table in the current hash table API.
>>
>> So, I'm not sure of the details yet, but it seems like it could
>> be made simpler somehow..
>
> After tossing it around in my head for a bit, the only thing that
> I see (so far) which might work is to maintain a *list* of
> SERIALIZABLEXACT objects in memory rather than a using a hash
> table. The recheck after releasing the shared lock and acquiring
> an exclusive lock would then go through SerializableXidHash. I
> think that can work, although I'm not 100% sure that it's an
> improvement. I'll look it over in more detail. I'd be happy to
> hear your thoughts on this or any other suggestions.
I haven't come up with any better ideas. Pondering this one, it
seems to me that a list would be better than a hash table if we had
a list which would automatically allocate and link new entries, and
would maintain a list of available entries for (re)use. I wouldn't
want to sprinkle such an implementation in with predicate locking
and SSI code, but if there is a feeling that such a thing would be
worth having in shmqueue.c or some new file which uses the SHM_QUEUE
structure to provide an API for such functionality, I'd be willing
to write that and use it in the SSI code. Without something like
that, I have so far been unable to envision an improvement along the
lines Heikki is suggesting here.
Thoughts?
-Kevin