Tomas Vondra <tomas.von...@enterprisedb.com> writes:
> True, but I can't reproduce it. So either the build is broken in some
> way, or perhaps there's something else going on. What would be quite
> helpful is a backtrace showing why the error was triggered. i.e. set a
> breakpoint on the ereport in mdread().
It reproduced as-described for me. The planner sees the index as
already indisvalid, so it figures it can ask for the tree height:
#0 errfinish (filename=0xa4c15c "md.c", lineno=686,
funcname=0xac6a98 <__func__.13643> "mdread") at elog.c:515
#1 0x00000000004dc8fb in mdread (reln=<optimized out>,
forknum=<optimized out>, blocknum=0, buffer=0x7fad931b4f80 "") at md.c:682
#2 0x00000000007fd15c in ReadBuffer_common (smgr=0x1d72140,
relpersistence=<optimized out>, forkNum=MAIN_FORKNUM, blockNum=0,
mode=RBM_NORMAL, strategy=<optimized out>, hit=0x7fff63a1d7af)
at bufmgr.c:1003
#3 0x00000000007fdb54 in ReadBufferExtended (reln=0x7fad9c4b69d8,
forkNum=MAIN_FORKNUM, blockNum=0, mode=<optimized out>,
strategy=<optimized out>) at ../../../../src/include/utils/rel.h:548
#4 0x00000000005797f5 in _bt_getbuf (rel=0x7fad9c4b69d8,
blkno=<optimized out>, access=1) at nbtpage.c:878
#5 0x0000000000579bc7 in _bt_getrootheight (rel=rel@entry=0x7fad9c4b69d8)
at nbtpage.c:680
#6 0x000000000078106a in get_relation_info (root=root@entry=0x1d84b28,
relationObjectId=59210, inhparent=false, rel=rel@entry=0x1d85290)
at plancat.c:419
#7 0x0000000000785451 in build_simple_rel (root=0x1d84b28, relid=1,
parent=0x0) at relnode.c:308
#8 0x000000000075792f in add_base_rels_to_query (root=root@entry=0x1d84b28,
jtnode=<optimized out>) at initsplan.c:122
#9 0x000000000075ac68 in query_planner (root=root@entry=0x1d84b28,
--Type <RET> for more, q to quit, c to continue without paging--q
regards, tom lane
