Thread
Commits
-
Fix CLUSTER on expression indexes.
- 6d3fe6b6bf05 12.1 landed
- cef82eda1464 13.0 landed
-
v12.0 ERROR: trying to store a heap tuple into wrong type of slot
Justin Pryzby <pryzby@telsasoft.com> — 2019-10-11T21:03:20Z
I'm not sure why we have that index, and my script probably should have known to choose a better one to cluster on, but still.. ts=# CLUSTER huawei_m2000_config_enodebcell_enodeb USING huawei_m2000_config_enodebcell_enodeb_coalesce_idx ; DEBUG: 00000: building index "pg_toast_1840151315_index" on table "pg_toast_1840151315" serially LOCATION: index_build, index.c:2791 DEBUG: 00000: clustering "public.huawei_m2000_config_enodebcell_enodeb" using sequential scan and sort LOCATION: copy_table_data, cluster.c:907 ERROR: XX000: trying to store a heap tuple into wrong type of slot LOCATION: ExecStoreHeapTuple, execTuples.c:1328 ts=# \dt+ huawei_m2000_config_enodebcell_enodeb public | huawei_m2000_config_enodebcell_enodeb | table | telsasoft | 3480 kB | ts=# \d+ huawei_m2000_config_enodebcell_enodeb_coalesce_idx Index "public.huawei_m2000_config_enodebcell_enodeb_coalesce_idx" Column | Type | Key? | Definition | Storage | Stats target ----------+------+------+---------------------------------------+----------+-------------- coalesce | text | yes | COALESCE(enodebfunctionname, ne_name) | extended | btree, for table "public.huawei_m2000_config_enodebcell_enodeb" ts=# \d+ huawei_m2000_config_enodebcell_enodeb ... Indexes: "huawei_m2000_config_enodebcell_enodeb_unique_idx" UNIQUE, btree (ne_name, tsoft_fake_key, device_name) "huawei_m2000_config_enodebcell_enodeb_cellid_idx" btree (cellid) CLUSTER "huawei_m2000_config_enodebcell_enodeb_coalesce_cellid_idx" btree (COALESCE(enodebfunctionname, ne_name), cellid) "huawei_m2000_config_enodebcell_enodeb_coalesce_idx" btree (COALESCE(enodebfunctionname, ne_name)) Statistics objects: "public"."huawei_m2000_config_enodebcell_enodeb" (ndistinct) ON ne_name, tsoft_fake_key, device_name FROM huawei_m2000_config_enodebcell_ enodeb Access method: heap (gdb) bt #0 errfinish (dummy=dummy@entry=0) at elog.c:411 #1 0x000000000087a959 in elog_finish (elevel=elevel@entry=20, fmt=fmt@entry=0x9c4d70 "trying to store a heap tuple into wrong type of slot") at elog.c:1365 #2 0x000000000061eea8 in ExecStoreHeapTuple (tuple=tuple@entry=0x1e06950, slot=slot@entry=0x1e05080, shouldFree=shouldFree@entry=false) at execTuples.c:1328 #3 0x00000000008a7a06 in comparetup_cluster (a=<optimized out>, b=<optimized out>, state=0x1e04940) at tuplesort.c:3795 #4 0x00000000008a5895 in qsort_tuple (a=0x2254b08, n=7699, cmp_tuple=0x8a7960 <comparetup_cluster>, state=state@entry=0x1e04940) at qsort_tuple.c:112 #5 0x00000000008a98bb in tuplesort_sort_memtuples (state=state@entry=0x1e04940) at tuplesort.c:3320 #6 0x00000000008ab434 in tuplesort_performsort (state=state@entry=0x1e04940) at tuplesort.c:1811 #7 0x00000000004c9404 in heapam_relation_copy_for_cluster (OldHeap=0x7f21606695d8, NewHeap=0x7f2160585048, OldIndex=<optimized out>, use_sort=<optimized out>, OldestXmin=288843233, xid_cutoff=<optimized out>, multi_cutoff=0x7ffc05e6ba04, num_tuples=0x7ffc05e6ba08, tups_vacuumed=0x7ffc05e6ba10, tups_recently_dead=0x7ffc05e6ba18) at heapam_handler.c:944 #8 0x000000000059cf07 in table_relation_copy_for_cluster (tups_recently_dead=0x7ffc05e6ba18, tups_vacuumed=0x7ffc05e6ba10, num_tuples=0x7ffc05e6ba08, multi_cutoff=0x7ffc05e6ba04, xid_cutoff=0x7ffc05e6ba00, OldestXmin=<optimized out>, use_sort=true, OldIndex=0x7f2160585f38, NewTable=0x7f2160585048, OldTable=0x7f21606695d8) at ../../../src/include/access/tableam.h:1410 #9 copy_table_data (pCutoffMulti=<synthetic pointer>, pFreezeXid=<synthetic pointer>, pSwapToastByContent=<synthetic pointer>, verbose=<optimized out>, OIDOldIndex=13, OIDOldHeap=1499600032, OIDNewHeap=1840150111) at cluster.c:920 #10 rebuild_relation (verbose=<optimized out>, indexOid=13, OldHeap=<optimized out>) at cluster.c:616 #11 cluster_rel (tableOid=tableOid@entry=1499600032, indexOid=indexOid@entry=3081287757, options=<optimized out>) at cluster.c:429 #12 0x000000000059d35e in cluster (stmt=stmt@entry=0x1d051f8, isTopLevel=isTopLevel@entry=true) at cluster.c:186 #13 0x000000000076547f in standard_ProcessUtility (pstmt=pstmt@entry=0x1d05518, queryString=queryString@entry=0x1d046e0 "CLUSTER huawei_m2000_config_enodebcell_enodeb USING huawei_m2000_config_enodebcell_enodeb_coalesce_idx ;", context=context@entry=PROCESS_UTILITY_TOPLEVEL, params=params@entry=0x0, queryEnv=queryEnv@entry=0x0, dest=dest@entry=0x1d055f8, completionTag=completionTag@entry=0x7ffc05e6c0a0 "") at utility.c:659 #14 0x00007f21517204ef in pgss_ProcessUtility (pstmt=0x1d05518, queryString=0x1d046e0 "CLUSTER huawei_m2000_config_enodebcell_enodeb USING huawei_m2000_config_enodebcell_enodeb_coalesce_idx ;", context=PROCESS_UTILITY_TOPLEVEL, params=0x0, queryEnv=0x0, dest=0x1d055f8, completionTag=0x7ffc05e6c0a0 "") at pg_stat_statements.c:1006 #15 0x0000000000762816 in PortalRunUtility (portal=0x1d7a4e0, pstmt=0x1d05518, isTopLevel=<optimized out>, setHoldSnapshot=<optimized out>, dest=0x1d055f8, completionTag=0x7ffc05e6c0a0 "") at pquery.c:1175 #16 0x0000000000763267 in PortalRunMulti (portal=portal@entry=0x1d7a4e0, isTopLevel=isTopLevel@entry=true, setHoldSnapshot=setHoldSnapshot@entry=false, dest=dest@entry=0x1d055f8, altdest=altdest@entry=0x1d055f8, completionTag=completionTag@entry=0x7ffc05e6c0a0 "") at pquery.c:1328 ---Type <return> to continue, or q <return> to quit--- #17 0x0000000000763e45 in PortalRun (portal=<optimized out>, count=9223372036854775807, isTopLevel=<optimized out>, run_once=<optimized out>, dest=0x1d055f8, altdest=0x1d055f8, completionTag=0x7ffc05e6c0a0 "") at pquery.c:796 #18 0x000000000075ff45 in exec_simple_query (query_string=<optimized out>) at postgres.c:1215 #19 0x0000000000761212 in PostgresMain (argc=<optimized out>, argv=<optimized out>, dbname=<optimized out>, username=<optimized out>) at postgres.c:4236 #20 0x0000000000483d02 in BackendRun (port=<optimized out>, port=<optimized out>) at postmaster.c:4431 #21 BackendStartup (port=0x1d2b340) at postmaster.c:4122 #22 ServerLoop () at postmaster.c:1704 #23 0x00000000006f0b1f in PostmasterMain (argc=argc@entry=3, argv=argv@entry=0x1cff280) at postmaster.c:1377 #24 0x0000000000484c93 in main (argc=3, argv=0x1cff280) at main.c:228 (gdb) #2 0x000000000061eea8 in ExecStoreHeapTuple (tuple=tuple@entry=0x1e06950, slot=slot@entry=0x1e05080, shouldFree=shouldFree@entry=false) at execTuples.c:1328 tuple = 0x1e06950 slot = 0x1e05080 shouldFree = 64 #3 0x00000000008a7a06 in comparetup_cluster (a=<optimized out>, b=<optimized out>, state=0x1e04940) at tuplesort.c:3795 l_index_values = {140720407492095, 139781285162339, 206158430232, 8920320, 20, 140720407492304, 0, 0, 31, 4294967295, 0, 139781288589152, 22, 540258, 139781288589152, 1, 13947976, 7541298, 139774490219072, 139774490219072, 31371296, 1, 433, 7550010, 2040109468721, 18435224211311474416, 0, 0, 140720407492471, 112, 140720407492335, 139779728308152} r_index_values = {70729521432191, 1840042467, 433, 2097168, 139781288589240, 139781285165739, 2097152, 17520358731135336960, 32768, 139781327984088, 0, 433, 433, 139778931751520, 31578680, 7552416, 140720407492471, 540257, 139774490219008, 7547611, 72197375326517088, 17520358731135336960, 0, 19, 31578680, 4970402, 31360768, 98368, 0, 540258, 568, 540258} ecxt_scantuple = 0x1e05080 l_index_isnull = {false <repeats 16 times>, 48, false, false, false, 91, false, false, false, 86, 101, 224, 93, 33, 127, false, false} r_index_isnull = {96, 119, 13, 94, 33, 127, false, false, 64, false, 3, false, false, false, false, false, 192, 74, 37, 2, false, false, false, false, 89, 155, 217, 93, 33, 127, false, false} sortKey = 0x1e05490 ltup = 0x1e06950 rtup = 0x1e06b60 tupDesc = <optimized out> nkey = 0 compare = <optimized out> datum1 = <optimized out> datum2 = <optimized out> isnull1 = false isnull2 = false leading = <optimized out> #4 0x00000000008a5895 in qsort_tuple (a=0x2254b08, n=7699, cmp_tuple=0x8a7960 <comparetup_cluster>, state=state@entry=0x1e04940) at qsort_tuple.c:112 pa = <optimized out> pb = <optimized out> pc = <optimized out> pd = <optimized out> pl = <optimized out> pm = 0x2254b20 pn = <optimized out> d1 = <optimized out> d2 = <optimized out> r = <optimized out> presorted = 1 #5 0x00000000008a98bb in tuplesort_sort_memtuples (state=state@entry=0x1e04940) at tuplesort.c:3320 No locals. #6 0x00000000008ab434 in tuplesort_performsort (state=state@entry=0x1e04940) at tuplesort.c:1811 oldcontext = 0x1de8700 __func__ = "tuplesort_performsort" #7 0x00000000004c9404 in heapam_relation_copy_for_cluster (OldHeap=0x7f21606695d8, NewHeap=0x7f2160585048, OldIndex=<optimized out>, use_sort=<optimized out>, OldestXmin=288843233, xid_cutoff=<optimized out>, multi_cutoff=0x7ffc05e6ba04, num_tuples=0x7ffc05e6ba08, tups_vacuumed=0x7ffc05e6ba10, tups_recently_dead=0x7ffc05e6ba18) at heapam_handler.c:944 n_tuples = 0 rwstate = 0x1dfe910 indexScan = 0x0 tableScan = 0x1e1da38 heapScan = 0x1e1da38 use_wal = <optimized out> is_system_catalog = false tuplesort = <optimized out> oldTupDesc = <optimized out> newTupDesc = <optimized out> slot = 0x1e1de48 values = 0x1e1c848 isnull = 0x1e1d9e8 hslot = 0x1e1de48 __func__ = "heapam_relation_copy_for_cluster" #8 0x000000000059cf07 in table_relation_copy_for_cluster (tups_recently_dead=0x7ffc05e6ba18, tups_vacuumed=0x7ffc05e6ba10, num_tuples=0x7ffc05e6ba08, multi_cutoff=0x7ffc05e6ba04, xid_cutoff=0x7ffc05e6ba00, OldestXmin=<optimized out>, use_sort=true, OldIndex=0x7f2160585f38, NewTable=0x7f2160585048, OldTable=0x7f21606695d8) at ../../../src/include/access/tableam.h:1410 No locals. #9 copy_table_data (pCutoffMulti=<synthetic pointer>, pFreezeXid=<synthetic pointer>, pSwapToastByContent=<synthetic pointer>, verbose=<optimized out>, OIDOldIndex=13, OIDOldHeap=1499600032, OIDNewHeap=1840150111) at cluster.c:920 relRelation = <optimized out> relform = <optimized out> newTupDesc = <optimized out> MultiXactCutoff = 22262 num_tuples = 7699 tups_recently_dead = 0 ru0 = {tv = {tv_sec = 1570827033, tv_usec = 106788}, ru = {ru_utime = {tv_sec = 0, tv_usec = 339198}, ru_stime = {tv_sec = 0, tv_usec = 77498}, {ru_maxrss = 111588, __ru_maxrss_word = 111588}, {ru_ixrss = 0, __ru_ixrss_word = 0}, {ru_idrss = 0, __ru_idrss_word = 0}, {ru_isrss = 0, __ru_isrss_word = 0}, {ru_minflt = 32814, __ru_minflt_word = 32814}, {ru_majflt = 0, __ru_majflt_word = 0}, {ru_nswap = 0, __ru_nswap_word = 0}, {ru_inblock = 0, __ru_inblock_word = 0}, {ru_oublock = 296, __ru_oublock_word = 296}, {ru_msgsnd = 0, __ru_msgsnd_word = 0}, {ru_msgrcv = 0, __ru_msgrcv_word = 0}, {ru_nsignals = 0, __ru_nsignals_word = 0}, {ru_nvcsw = 41, __ru_nvcsw_word = 41}, {ru_nivcsw = 46, __ru_nivcsw_word = 46}}} oldTupDesc = <optimized out> OldHeap = 0x7f21606695d8 reltup = <optimized out> use_sort = <optimized out> tups_vacuumed = 0 num_pages = <optimized out> NewHeap = 0x7f2160585048 OldIndex = 0x7f2160585f38 OldestXmin = 288843233 FreezeXid = 288843233 elevel = 13 #10 rebuild_relation (verbose=<optimized out>, indexOid=13, OldHeap=<optimized out>) at cluster.c:616 tableOid = 1499600032 tableSpace = <optimized out> OIDNewHeap = 1840150111 relpersistence = 112 'p' swap_toast_by_content = true frozenXid = <optimized out> is_system_catalog = false cutoffMulti = <optimized out> #11 cluster_rel (tableOid=tableOid@entry=1499600032, indexOid=indexOid@entry=3081287757, options=<optimized out>) at cluster.c:429 OldHeap = <optimized out> verbose = <optimized out> recheck = <optimized out> __func__ = "cluster_rel" #12 0x000000000059d35e in cluster (stmt=stmt@entry=0x1d051f8, isTopLevel=isTopLevel@entry=true) at cluster.c:186 tableOid = 1499600032 indexOid = 3081287757 rel = 0x7f21606695d8 __func__ = "cluster" #13 0x000000000076547f in standard_ProcessUtility (pstmt=pstmt@entry=0x1d05518, queryString=queryString@entry=0x1d046e0 "CLUSTER huawei_m2000_config_enodebcell_enodeb USING huawei_m2000_config_enodebcell_enodeb_coalesce_idx ;", context=context@entry=PROCESS_UTILITY_TOPLEVEL, params=params@entry=0x0, queryEnv=queryEnv@entry=0x0, dest=dest@entry=0x1d055f8, completionTag=completionTag@entry=0x7ffc05e6c0a0 "") at utility.c:659 parsetree = 0x1d051f8 isTopLevel = true isAtomicContext = false pstate = 0x1de8810 __func__ = "standard_ProcessUtility" -
Re: v12.0 ERROR: trying to store a heap tuple into wrong type of slot
Andres Freund <andres@anarazel.de> — 2019-10-13T14:51:06Z
Hi, On 2019-10-11 16:03:20 -0500, Justin Pryzby wrote: > I'm not sure why we have that index, and my script probably should have known > to choose a better one to cluster on, but still.. > > ts=# CLUSTER huawei_m2000_config_enodebcell_enodeb USING huawei_m2000_config_enodebcell_enodeb_coalesce_idx ; > DEBUG: 00000: building index "pg_toast_1840151315_index" on table "pg_toast_1840151315" serially > LOCATION: index_build, index.c:2791 > DEBUG: 00000: clustering "public.huawei_m2000_config_enodebcell_enodeb" using sequential scan and sort > LOCATION: copy_table_data, cluster.c:907 > ERROR: XX000: trying to store a heap tuple into wrong type of slot > LOCATION: ExecStoreHeapTuple, execTuples.c:1328 Well, that's annoying. There apparently is not a single test covering cluster on expression indexes, that' really ought to not be the case. Equally annoying that I just broke this without noticing at all :(. The cause of the error is that, while that sounds like it should be the case, a virtual slot isn't sufficient for tuplesort_begin_cluster(). So the fix is pretty trivial. Will fix. I started a separate thread about test coverage of tuplesort at https://www.postgresql.org/message-id/20191013144153.ooxrfglvnaocsrx2%40alap3.anarazel.de Greetings, Andres Freund
-
Re: v12.0 ERROR: trying to store a heap tuple into wrong type of slot
Andres Freund <andres@anarazel.de> — 2019-10-15T20:50:09Z
Hi, On 2019-10-13 07:51:06 -0700, Andres Freund wrote: > On 2019-10-11 16:03:20 -0500, Justin Pryzby wrote: > > I'm not sure why we have that index, and my script probably should have known > > to choose a better one to cluster on, but still.. > > > > ts=# CLUSTER huawei_m2000_config_enodebcell_enodeb USING huawei_m2000_config_enodebcell_enodeb_coalesce_idx ; > > DEBUG: 00000: building index "pg_toast_1840151315_index" on table "pg_toast_1840151315" serially > > LOCATION: index_build, index.c:2791 > > DEBUG: 00000: clustering "public.huawei_m2000_config_enodebcell_enodeb" using sequential scan and sort > > LOCATION: copy_table_data, cluster.c:907 > > ERROR: XX000: trying to store a heap tuple into wrong type of slot > > LOCATION: ExecStoreHeapTuple, execTuples.c:1328 > > Well, that's annoying. There apparently is not a single test covering > cluster on expression indexes, that' really ought to not be the > case. Equally annoying that I just broke this without noticing at all > :(. > > The cause of the error is that, while that sounds like it should be the > case, a virtual slot isn't sufficient for tuplesort_begin_cluster(). So > the fix is pretty trivial. Will fix. I pushed the fix, including a few tests, a few hours ago. I hope that fixes the issue for you? Greetings, Andres Freund
-
Re: v12.0 ERROR: trying to store a heap tuple into wrong type of slot
Justin Pryzby <pryzby@telsasoft.com> — 2019-10-15T22:26:59Z
On Tue, Oct 15, 2019 at 01:50:09PM -0700, Andres Freund wrote: > On 2019-10-13 07:51:06 -0700, Andres Freund wrote: > > On 2019-10-11 16:03:20 -0500, Justin Pryzby wrote: > > > ts=# CLUSTER huawei_m2000_config_enodebcell_enodeb USING huawei_m2000_config_enodebcell_enodeb_coalesce_idx ; > > The cause of the error is that, while that sounds like it should be the > > case, a virtual slot isn't sufficient for tuplesort_begin_cluster(). So > > the fix is pretty trivial. Will fix. > > I pushed the fix, including a few tests, a few hours ago. I hope that > fixes the issue for you? On another server already running REL_12_STABLE, I created index with same definition, which didn't previously exist. I failed before pulling and works after. ts=# CLUSTER huawei_m2000_config_enodebcell_enodeb USING huawei_m2000_config_enodebcell_enodeb_coalesce_idx ; CLUSTER Thanks, Justin