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