From: | Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at> |
---|---|
To: | "'Tom Lane *EXTERN*'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Index created in BEFORE trigger not updated during INSERT |
Date: | 2017-06-06 13:24:08 |
Message-ID: | A737B7A37273E048B164557ADEF4A58B53A538A9@ntex2010i.host.magwien.gv.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
>> Andres Freund <andres(at)anarazel(dot)de> writes:
>>> Hm, strategically sprinkled CheckTableNotInUse() might do the trick?
>
> Attached is a proposed patch that closes off this problem. I've tested
> it to the extent that it blocks Albe's example and passes check-world.
I tested it, and it works fine. Thanks!
> I'm unsure whether to back-patch or not; the main argument for not doing
> so is that if any extensions are calling DefineIndex() directly, this
> would be an API break for them. Given what a weird case this is, I'm not
> sure it's worth that.
>
> A possible end-run around the API objection would be to not add an extra
> argument to DefineIndex() in the back branches, but to use !is_alter_table
> as the control condition. That would work for the core callers, although
> we might need a special case for bootstrap mode. On the other hand,
> thinking again about hypothetical third-party callers, it's possible that
> that's not the right answer for them, in which case they'd be really in
> trouble. So I'm not that much in love with that answer.
It causes a slight bellyache to leave an unfixed data corruption bug
in the back branches (if only index corruption), but I agree that it is
such a weird case to create an index in a BEFORE trigger that we probably
can live without a back-patch.
Yours,
Laurenz Albe
From | Date | Subject | |
---|---|---|---|
Next Message | Sven R. Kunze | 2017-06-06 13:51:54 | Re: Use of non-restart-safe storage by temp_tablespaces |
Previous Message | Bruce Momjian | 2017-06-06 13:09:40 | Re: Challenges preventing us moving to 64 bit transaction id (XID)? |