From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: pgsql-hackers@postgresql.org <pgsql-hackers@postgresql.org>
Subject: Re: Catalog invalidations vs catalog scans vs ScanPgRelation()
Date: Thu, 09 Apr 2020 18:52:32 -0400
Message-ID: <15495.1586472752@sss.pgh.pa.us> (raw)
In-Reply-To: <20200409223249.pmezmufk24z7t5wu@alap3.anarazel.de>
References: <20200229052459.wzhqnbhrriezg4v2@alap3.anarazel.de>
<20200229061052.qceiitudgo5es3ns@alap3.anarazel.de>
<20200229201707.jvmau4x5nof2dywx@alap3.anarazel.de>
<CA+TgmoYaFYRRdRZ94p_Qdt+1oONg6sMOvbkGHKVsFtONCrFkhw@mail.gmail.com>
<20200409223249.pmezmufk24z7t5wu@alap3.anarazel.de>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, andres@anarazel.de, robertmhaas@gmail.com
Subject: Re: Catalog invalidations vs catalog scans vs ScanPgRelation()
In-Reply-To: <15495.1586472752@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox