At Thu, 2 Aug 2018 14:40:50 -0700, Peter Geoghegan <p...@bowt.ie> wrote in <cah2-wznj8k1hxltkoy53qbw2dty0z53xkb-0rpqsjqbs0tk...@mail.gmail.com> pg> On Thu, Aug 2, 2018 at 3:18 AM, Kyotaro HORIGUCHI pg> <horiguchi.kyot...@lab.ntt.co.jp> wrote: pg> >> [1] http://archives.postgresql.org/message-id/CAKoxK%2B5fVodiCtMsXKV_1YAKXbzwSfp7DgDqUmcUAzeAhf%3DHEQ%40mail.gmail.com pg> >> [2] https://www.postgresql.org/message-id/12259.1532117...@sss.pgh.pa.us pg> > pg> > As for [1], it is not a issue on invalidation. It happens also if pg> > the relation has any index and even drop is not needed. The pg> > following steps are sufficient. pg> > pg> > create table t( pk serial, t text ); pg> > insert into t( t ) values( 'hello' ), ('world'); pg> > create index idx_fake0 on t (pk); pg> > create index idx_fake on t ( f_fake( pk ) ); -- ERROR pg> pg> The fact that there was a weird error wasn't really what we cared pg> about there. If the user is doing something that's clearly pg> unreasonable or nonsensical, then they cannot expect much from the pg> error message (maybe we could do better, but it's not a priority).
Hmm. I don't think it's unreasonable or nonsensical, but I don't argue it here. pg> What we really cared about was the fact that it was possible to make a pg> backend's relcache irrecoverably corrupt. That should never be allowed pg> to happen, even when the user is determined to do something pg> unreasonable. I reread through the thread and IUCC, drop_index() is sending inval on the owing relation and invalidation happens (that is, RelationCacheInvalidateEntry is called for the owner relation.). Relcache for the owner is actually being rebuit during the following create index. At least the problem mentioned in [1] is happening using a fresh relcache created after invoking the index creation. The cause is RelationGetIndexList collects all "indislive" indexes, including the idx_fake before population, which can be fixed by the attached patch.. I'm I still misunderstanding something? # Anyway, I'll make another thread for the another issue. [1]: https://www.postgresql.org/message-id/20180628150209.n2qch5jtn3vt2xaa%40alap3.anarazel.de regards. -- Kyotaro Horiguchi NTT Open Source Software Center
