Hi, On 2020-04-09 18:52:32 -0400, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > On 2020-04-09 16:56:03 -0400, Robert Haas wrote: > >> That seems like a fairly magical coding rule that will happen to work > >> in most practical cases but isn't really a principled approach to the > >> problem. > > > I'm not sure it'd be that magical to only release resources at > > CommitTransactionCommand() time. We kinda do that for a few other things > > already. > > I'd be worried about consumption of resources during a long transaction. > But maybe we could release at CommandCounterIncrement?
Which resources are you thinking of? SnapshotResetXmin() shouldn't take any directly. Obviously it can cause bloat - but where would we use a snapshot for only some part of a command, but need not have xmin preserved till the end of the command? > Still, I tend to agree with Robert that associating a snap with an > open catalog scan is the right way. I'm wondering if we should do both. I think releasing xmin in the middle of a command, but only when invalidations arrive in the middle of it, is pretty likely to be involved in bugs in the future. But it also seems good to ensure that snapshots are held across relevant operations. Any idea how to deal with different types of snapshots potentially being used within such a sequence? > I have vague memories that a long time ago, all catalog modifications > were done via the fetch-from-a- scan-and-update approach. Starting > from a catcache tuple instead is a relative newbie. If we're going to > forbid using a catcache tuple as the starting point for updates, one > way to enforce it would be to have the catcache not save the TID. I suspect that that'd be fairly painful code-churn wise. Greetings, Andres Freund
