Heikki Linnakangas <heikki.linnakan...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
