On 2019-Sep-26, Tomas Vondra wrote: > Hi, > > Attached is an updated patch series, rebased on current master. It does > fix one memory accounting bug in ReorderBufferToastReplace (the code was > not properly updating the amount of memory).
Cool. Can we aim to get 0001 pushed during this commitfest, or is that a lost cause? The large new comment in reorderbuffer.c says that a transaction might get spilled *or streamed*, but surely that second thing is not correct, since before the subsequent patches it's not possible to stream transactions that have not yet finished? How certain are you about the approach to measure memory used by a reorderbuffer transaction ... does it not cause a measurable performance drop? I wonder if it would make more sense to use a separate contexts per transaction and use context-level accounting (per the patch Jeff Davis posted elsewhere for hash joins ... though I see now that that only works fot aset.c, not other memcxt implementations), or something like that. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services