Re: Large expressions in indexes can't be stored (non-TOASTable)

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Nathan Bossart <nathandbossart(at)gmail(dot)com>
Cc: Alexander Lakhin <exclusion(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Large expressions in indexes can't be stored (non-TOASTable)
Date: 2024-11-27 06:20:19
Message-ID: Z0a6IwjW36af71J7@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Nov 25, 2024 at 01:29:31PM -0600, Nathan Bossart wrote:
> Or we could just enforce that you have an active snapshot whenever you
> modify a catalog with a TOAST table. That's simpler, but it requires extra
> work in some paths (and probably comments to point out that we're only
> pushing an active snapshot to satisfy an assertion).

I may be wrong, but I suspect that enforcing the check without being
column-based is the right way to go and that this is going to catch
more errors in the long-term than being a maintenance burden. So I
would keep the snapshot check even if it's a bit aggressive, still
it's useful. And we are not talking about that may code paths that
need to be switched to require a snapshot, as well. Most of the ones
you have mentioned on this thread are really particular in the ways
they do transaction handling. I suspect that it may also catch
out-of-core issues with extensions doing direct catalog manipulations.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2024-11-27 06:33:38 Re: per backend I/O statistics
Previous Message vignesh C 2024-11-27 06:01:30 Re: Skip collecting decoded changes of already-aborted transactions