Re: Catalog invalidations vs catalog scans vs ScanPgRelation()
От | Tom Lane |
---|---|
Тема | Re: Catalog invalidations vs catalog scans vs ScanPgRelation() |
Дата | |
Msg-id | 15495.1586472752@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Catalog invalidations vs catalog scans vs ScanPgRelation() (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: Catalog invalidations vs catalog scans vs ScanPgRelation()
|
Список | 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
В списке pgsql-hackers по дате отправления: