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.
-Kevin
