Re: Missing update of all_hasnulls in BRIN opclasses - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Missing update of all_hasnulls in BRIN opclasses
Date
Msg-id 20230425092040.epmbot5pzfg6ncrq@alvherre.pgsql
Whole thread Raw
In response to Re: Missing update of all_hasnulls in BRIN opclasses  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
List pgsql-hackers
On 2023-Apr-24, Tomas Vondra wrote:

> On 4/24/23 17:36, Alvaro Herrera wrote:

> > (As for your FIXME comment in brin_memtuple_initialize, I think you're
> > correct: we definitely need to reset bt_placeholder.  Otherwise, we risk
> > places that call it in a loop using a BrinMemTuple with one range with
> > the flag set, in a range where that doesn't hold.  It might be
> > impossible for this to happen, given how narrow the conditions are on
> > which bt_placeholder is used; but it seems safer to reset it anyway.)
> 
> Yeah. But isn't that a separate preexisting issue, strictly speaking?

Yes.

> > I did a quick experiment of turning the patches over -- applying test
> > first, code fix after (requires some conflict fixing).  With that I
> > verified that the behavior of 'hasnulls' indeed changes with the code
> > fix.
> 
> Thanks. Could you do some testing of the union_tuples stuff too? It's a
> bit tricky part - the behavior is timing sensitive, so testing it
> requires gdb breakpoints breakpoints or something like that. I think
> it's correct, but it'd be nice to check that.

I'll have a look.

-- 
Álvaro Herrera        Breisgau, Deutschland  —  https://www.EnterpriseDB.com/
<inflex> really, I see PHP as like a strange amalgamation of C, Perl, Shell
<crab> inflex: you know that "amalgam" means "mixture with mercury",
       more or less, right?
<crab> i.e., "deadly poison"



pgsql-hackers by date:

Previous
From: Kyotaro Horiguchi
Date:
Subject: Re: Allow pg_archivecleanup to remove backup history files
Next
From: Richard Guo
Date:
Subject: Re: postgres_fdw: wrong results with self join + enable_nestloop off