Re: Catalog invalidations vs catalog scans vs ScanPgRelation()
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Robert Haas <robertmhaas@gmail.com>,
"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2020-04-09T22:52:32Z
Lists: pgsql-hackers
Andres Freund <andres@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? Still, I tend to agree with Robert that associating a snap with an open catalog scan is the right way. 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. regards, tom lane
Commits
-
Ensure snapshot is registered within ScanPgRelation().
- 42750b08d946 13.0 landed
- 820f21a93f0b 9.5.22 landed
- 211d8f65392f 9.6.18 landed
- a0e2a178c640 10.13 landed
- 00a0a428ef50 11.8 landed
- 1d377f203ea4 12.3 landed