From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Tomas Vondra <tomas.vondra@enterprisedb.com>
Cc: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Cc: pgsql-hackers@postgresql.org
Subject: Re: Fix brin_form_tuple to properly detoast data
Date: Thu, 5 Nov 2020 18:16:04 -0300
Message-ID: <20201105211604.GA3054@alvherre.pgsql> (raw)
In-Reply-To: <21cacd39-1ca2-54ef-4f3e-ac493238832c@enterprisedb.com>
On 2020-Nov-05, Tomas Vondra wrote:
> On 11/5/20 6:17 PM, Alvaro Herrera wrote:
> > There are recent changes in vacuum for temp tables (commit 94bc27b57680?)
> > that would maybe make this stable enough, without having to have the CIC
> > there. At least, I tried it locally a few times and it appears to work well.
> > This won't work for older releases though, just master. This is patch
> > 0001 attached here.
>
> IIUC you're suggesting to use a temporary table in the test? Unfortunately,
> this does not work on older releases, and IMHO the test should be
> backpatched too. IMHO the CIC "hack" is acceptable, unless there's a better
> solution that I'm not aware of.
Oh, sure, the CIC hack is acceptable for the older branches. I'm just
saying that you can use a temp table everywhere, and keep CIC in the old
branches and no CIC in master.
> This got me thinking though - wouldn't it be better to handle too large
> values by treating the range as "degenerate" (i.e. store NULL and consider
> it as matching all queries), instead of failing the CREATE INDEX or DML? I
> find the current behavior rather annoying, because it depends on the other
> rows in the page range, not just on the one row the user deals with. Perhaps
> this might even be considered an information leak about the other data. Of
> course, not something this patch should deal with.
Hmm. Regarding text I remember thinking we could just truncate values
(as we do for LIKE, as I recall). I suppose that strategy would work
even for bytea.
> > > +/*
> > > + * This enables de-toasting of index entries. Needed until VACUUM is
> > > + * smart enough to rebuild indexes from scratch.
> > > + */
> >
> > ... because, surely, we're now never working on having VACUUM rebuild
> > indexes from scratch. In fact, I wonder if we need the #define at
> > all. I propose to remove all those #ifdef lines in your patch.
>
> That's a verbatim copy of a comment from indextuple.c. IMHO we should keep
> it the same in both places.
Sure, if you want to.
> > The fix looks good to me. I just added a comment in 0003.
>
> Thanks. Any opinions on fixing this in existing clusters? Any better ideas
> than just giving users the SQL query to list possibly-affected indexes?
None here.
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: alvherre@alvh.no-ip.org, tomas.vondra@enterprisedb.com, tomas.vondra@2ndquadrant.com
Subject: Re: Fix brin_form_tuple to properly detoast data
In-Reply-To: <20201105211604.GA3054@alvherre.pgsql>
* 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