Re: Making all nbtree entries unique by having heap TIDs participate in comparisons

On 05/03/2019 05:16, Peter Geoghegan wrote:
> Attached is v14, which has changes based on your feedback.
As a quick check of the backwards-compatibility code, i.e.
!heapkeyspace, I hacked _bt_initmetapage to force the version number to
3, and ran the regression tests. It failed an assertion in the
'create_index' test:

(gdb) bt
#0 __GI_raise (sig=sig(at)entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x00007f2943f9a535 in __GI_abort () at abort.c:79
#2 0x00005622c7d9d6b4 in ExceptionalCondition
(conditionName=0x5622c7e4cbe8 "!(_bt_check_natts(rel, key->heapkeyspace,
page, offnum))", errorType=0x5622c7e4c62a "FailedAssertion",
fileName=0x5622c7e4c734 "nbtsearch.c", lineNumber=511) at assert.c:54
#3 0x00005622c78627fb in _bt_compare (rel=0x5622c85afbe0,
key=0x7ffd7a996db0, page=0x7f293d433780 "", offnum=2) at nbtsearch.c:511
#4 0x00005622c7862640 in _bt_binsrch (rel=0x5622c85afbe0,
key=0x7ffd7a996db0, buf=4622) at nbtsearch.c:432
#5 0x00005622c7861ec9 in _bt_search (rel=0x5622c85afbe0,
key=0x7ffd7a996db0, bufP=0x7ffd7a9976d4, access=1,
snapshot=0x5622c8353740) at nbtsearch.c:142
#6 0x00005622c7863a44 in _bt_first (scan=0x5622c841e828,
dir=ForwardScanDirection) at nbtsearch.c:1183
#7 0x00005622c785f8b0 in btgettuple (scan=0x5622c841e828,
dir=ForwardScanDirection) at nbtree.c:245
#8 0x00005622c78522e3 in index_getnext_tid (scan=0x5622c841e828,
direction=ForwardScanDirection) at indexam.c:542
#9 0x00005622c7a67784 in IndexOnlyNext (node=0x5622c83ad280) at
nodeIndexonlyscan.c:120
#10 0x00005622c7a438d5 in ExecScanFetch (node=0x5622c83ad280,
accessMtd=0x5622c7a67254 <IndexOnlyNext>, recheckMtd=0x5622c7a67bc9
<IndexOnlyRecheck>) at execScan.c:95
#11 0x00005622c7a4394a in ExecScan (node=0x5622c83ad280,
accessMtd=0x5622c7a67254 <IndexOnlyNext>, recheckMtd=0x5622c7a67bc9
<IndexOnlyRecheck>) at execScan.c:145
#12 0x00005622c7a67c73 in ExecIndexOnlyScan (pstate=0x5622c83ad280) at
nodeIndexonlyscan.c:322
#13 0x00005622c7a41814 in ExecProcNodeFirst (node=0x5622c83ad280) at
execProcnode.c:445
#14 0x00005622c7a501a5 in ExecProcNode (node=0x5622c83ad280) at
../../../src/include/executor/executor.h:231
#15 0x00005622c7a50693 in fetch_input_tuple (aggstate=0x5622c83acdd0) at
nodeAgg.c:406
#16 0x00005622c7a529d9 in agg_retrieve_direct (aggstate=0x5622c83acdd0)
at nodeAgg.c:1737
#17 0x00005622c7a525a9 in ExecAgg (pstate=0x5622c83acdd0) at nodeAgg.c:1552
#18 0x00005622c7a41814 in ExecProcNodeFirst (node=0x5622c83acdd0) at
execProcnode.c:445
#19 0x00005622c7a3621d in ExecProcNode (node=0x5622c83acdd0) at
../../../src/include/executor/executor.h:231
#20 0x00005622c7a38bd9 in ExecutePlan (estate=0x5622c83acb78,
planstate=0x5622c83acdd0, use_parallel_mode=false, operation=CMD_SELECT,
sendTuples=true, numberTuples=0,
direction=ForwardScanDirection, dest=0x5622c8462088,
execute_once=true) at execMain.c:1645
#21 0x00005622c7a36872 in standard_ExecutorRun
(queryDesc=0x5622c83a9eb8, direction=ForwardScanDirection, count=0,
execute_once=true) at execMain.c:363
#22 0x00005622c7a36696 in ExecutorRun (queryDesc=0x5622c83a9eb8,
direction=ForwardScanDirection, count=0, execute_once=true) at
execMain.c:307
#23 0x00005622c7c357dc in PortalRunSelect (portal=0x5622c8336778,
forward=true, count=0, dest=0x5622c8462088) at pquery.c:929
#24 0x00005622c7c3546f in PortalRun (portal=0x5622c8336778,
count=9223372036854775807, isTopLevel=true, run_once=true,
dest=0x5622c8462088, altdest=0x5622c8462088,
completionTag=0x7ffd7a997d50 "") at pquery.c:770
#25 0x00005622c7c2f029 in exec_simple_query (query_string=0x5622c82cf508
"SELECT count(*) FROM onek_with_null WHERE unique1 IS NULL AND unique2
IS NULL;") at postgres.c:1215
#26 0x00005622c7c3369a in PostgresMain (argc=1, argv=0x5622c82faee0,
dbname=0x5622c82fac50 "regression", username=0x5622c82c81e8 "heikki") at
postgres.c:4256
#27 0x00005622c7b8bcf2 in BackendRun (port=0x5622c82f3d80) at
postmaster.c:4378
#28 0x00005622c7b8b45b in BackendStartup (port=0x5622c82f3d80) at
postmaster.c:4069
#29 0x00005622c7b87633 in ServerLoop () at postmaster.c:1699
#30 0x00005622c7b86e61 in PostmasterMain (argc=3, argv=0x5622c82c6160)
at postmaster.c:1372
#31 0x00005622c7aa9925 in main (argc=3, argv=0x5622c82c6160) at main.c:228

I haven't investigated any deeper, but apparently something's broken.
This was with patch v14, without any further changes.

- Heikki