Re: Making all nbtree entries unique by having heap TIDs participatein comparisons
От | Heikki Linnakangas |
---|---|
Тема | Re: Making all nbtree entries unique by having heap TIDs participatein comparisons |
Дата | |
Msg-id | 97c179ee-7bca-e52b-7f03-b2e52215dd32@iki.fi обсуждение исходный текст |
Ответ на | Re: Making all nbtree entries unique by having heap TIDs participatein comparisons (Peter Geoghegan <pg@bowt.ie>) |
Ответы |
Re: Making all nbtree entries unique by having heap TIDs participatein comparisons
|
Список | pgsql-hackers |
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@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
В списке pgsql-hackers по дате отправления:
Следующее
От: Georgios KokolatosДата:
Сообщение: Re: Tighten error control for OpenTransientFile/CloseTransientFile