relcache sometimes initially ignores has_generated_stored - Mailing list pgsql-hackers

From Andres Freund
Subject relcache sometimes initially ignores has_generated_stored
Date
Msg-id 20200115181105.ad6ab6dlgyww3lb6@alap3.anarazel.de
Whole thread Raw
Responses Re: relcache sometimes initially ignores has_generated_stored  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Re: relcache sometimes initially ignores has_generated_stored  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-hackers
Hi,

I think it's probably not relevant, but it confused me for a moment
that RelationBuildTupleDesc() might set constr->has_generated_stored to
true, but then throw away the constraint at the end, because nothing
matches the
    /*
     * Set up constraint/default info
     */
    if (has_not_null || ndef > 0 ||
        attrmiss || relation->rd_rel->relchecks)
test, i.e. there are no defaults.

A quick assert confirms we do indeed pfree() constr in cases where
has_generated_stored == true.

I suspect that's just an intermediate catalog, however, e.g. when
DefineRelation() does
heap_create_with_catalog();
CommandCounterIncrement();
relation_open();
AddRelationNewConstraints().

It does still strike me as not great that we can get a different
relcache entry, even if transient, depending on whether there are other
reasons to create a TupleConstr. Say a NOT NULL column.

I'm inclined to think we should just also check has_generated_stored in
the if quoted above?

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Daniel Gustafsson
Date:
Subject: Re: Improve errors when setting incorrect bounds for SSL protocols
Next
From: Tom Lane
Date:
Subject: Re: Rearranging ALTER TABLE to avoid multi-operations bugs