From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Catalog invalidations vs catalog scans vs ScanPgRelation() |
Date: | 2020-04-09 22:52:32 |
Message-ID: | 15495.1586472752@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Michail Nikolaev | 2020-04-09 23:02:44 | Re: Thoughts on "killed tuples" index hint bits support on standby |
Previous Message | Bruce Momjian | 2020-04-09 22:44:48 | Re: where should I stick that backup? |