Re: Catalog invalidations vs catalog scans vs ScanPgRelation() - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Catalog invalidations vs catalog scans vs ScanPgRelation()
Date
Msg-id 15495.1586472752@sss.pgh.pa.us
Whole thread Raw
In response to Re: Catalog invalidations vs catalog scans vs ScanPgRelation()  (Andres Freund <andres@anarazel.de>)
Responses Re: Catalog invalidations vs catalog scans vs ScanPgRelation()  (Andres Freund <andres@anarazel.de>)
List 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 by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: where should I stick that backup?
Next
From: Michail Nikolaev
Date:
Subject: Re: Thoughts on "killed tuples" index hint bits support on standby