Re: v12.0 ERROR: trying to store a heap tuple into wrong type of slot

2019-10-15 Thread Justin Pryzby 
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

Re: v12.0 ERROR: trying to store a heap tuple into wrong type of slot

2019-10-15 Thread Andres Freund 
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:  0: building index "pg_toast_1840151315_index" on table 
> > "pg_toast_1840151315" serially
> > LOCATION:  index_build, index.c:2791
> > DEBUG:  0: 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

2019-10-13 Thread Andres Freund 
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:  0: building index "pg_toast_1840151315_index" on table 
> "pg_toast_1840151315" serially
> LOCATION:  index_build, index.c:2791
> DEBUG:  0: 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

v12.0 ERROR: trying to store a heap tuple into wrong type of slot

2019-10-11 Thread Justin Pryzby 
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:  0: building index "pg_toast_1840151315_index" on table 
"pg_toast_1840151315" serially
LOCATION:  index_build, index.c:2791
DEBUG:  0: 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  0x0087a959 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  0x0061eea8 in ExecStoreHeapTuple (tuple=tuple@entry=0x1e06950, 
slot=slot@entry=0x1e05080, shouldFree=shouldFree@entry=false)
at execTuples.c:1328
#3  0x008a7a06 in comparetup_cluster (a=, b=, state=0x1e04940) at tuplesort.c:3795
#4  0x008a5895 in qsort_tuple (a=0x2254b08, n=7699, cmp_tuple=0x8a7960 
, state=state@entry=0x1e04940)
at qsort_tuple.c:112
#5  0x008a98bb in tuplesort_sort_memtuples 
(state=state@entry=0x1e04940) at tuplesort.c:3320
#6  0x008ab434 in tuplesort_performsort (state=state@entry=0x1e04940) 
at tuplesort.c:1811
#7  0x004c9404 in heapam_relation_copy_for_cluster 
(OldHeap=0x7f21606695d8, NewHeap=0x7f2160585048, OldIndex=,
use_sort=, OldestXmin=288843233, xid_cutoff=, 
multi_cutoff=0x7ffc05e6ba04, num_tuples=0x7ffc05e6ba08,
tups_vacuumed=0x7ffc05e6ba10, tups_recently_dead=0x7ffc05e6ba18) at 
heapam_handler.c:944
#8  0x0059cf07 in table_relation_copy_for_cluster 
(tups_recently_dead=0x7ffc05e6ba18, tups_vacuumed=0x7ffc05e6ba10,
num_tuples=0x7ffc05e6ba08, multi_cutoff=0x7ffc05e6ba04, 
xid_cutoff=0x7ffc05e6ba00, OldestXmin=, use_sort=true,
OldIndex=0x7f2160585f38, NewTable=0x7f2160585048, OldTable=0x7f21606695d8) 
at ../../../src/include/access/tableam.h:1410
#9  copy_table_data (pCutoffMulti=, pFreezeXid=, pSwapToastByContent=,
verbose=, OIDOldIndex=13, OIDOldHeap=1499600032, 
OIDNewHeap=1840150111) at cluster.c:920
#10 rebuild_relation (verbose=, indexOid=13, OldHeap=) at cluster.c:616
#11 cluster_rel (tableOid=tableOid@entry=1499600032, 
indexOid=indexOid@entry=3081287757, options=) at cluster.c:429
#12 0x0059d35e in cluster (stmt=stmt@entry=0x1d051f8, 
isTopLevel=isTopLevel@entry=true) at cluster.c:186
#13 0x0076547f 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 0x7f21517204ef 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 0x00762816 in PortalRunUtility (portal=0x1d7a4e0, pstmt=0x1d05518, 
isTopLevel=, setHoldSnapshot=,
dest=0x1d055f8, completionTag=0x7ffc05e6c0a0 "") at pquery.c:1175
#16 0x00763267 in PortalRunMulti (portal=portal@entry=0x1d7a4e0, 
isTopLevel=isTopLevel@entry=true,
setHoldSnapshot=setHoldSnapshot@entry=false,