On Wed, Aug 3, 2022 at 4:14 PM Andres Freund <and...@anarazel.de> wrote: > I don't think this scenario would fundamentally change - we already keep the > set of subxids in backend local memory (e.g. either a dedicated > TransactionStateData or an element in ->childXids) and in the locking table > (via XactLockTableInsert()).
Sure.... > The problematic part isn't keeping "actually" running subxids in memory, but > keeping subxids that might be "considered running" in memory (i.e. subxids > that are considered running by an old snapshot in another backend). > > A hashtable just containing child->parent mapping for subxids doesn't actually > need that much memory. It'd be approximately (2 * 4 bytes) * subxids * > (2-fillfactor) or such? So maybe ~10MB for 1 milllion subxids? Allocating > that on-demand doesn't strike me as prohibitive. I mean the worst case is ~2 bn, no? -- Robert Haas EDB: http://www.enterprisedb.com