[sqlsmith] PANIC: failed to add BRIN tuple

From: Andreas Seltenreich <seltenreich(at)gmx(dot)de>
To: pgsql-hackers(at)postgresql(dot)org
Subject: [sqlsmith] PANIC: failed to add BRIN tuple
Date: 2016-05-22 09:42:42
Message-ID: 87mvni77jh.fsf@elite.ansel.ydns.eu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

There was one instance of this PANIC when testing with the regression db
of master at 50e5315.

,----
| WARNING: specified item offset is too large
| PANIC: failed to add BRIN tuple
| server closed the connection unexpectedly
`----

It is reproducible with the query below on this instance only. I've put
the data directory (20MB) here:

http://ansel.ydns.eu/~andreas/brincrash.tar.xz

The instance was running on Debian Jessie amd64. Query and Backtrace
below.

regards,
Andreas

--8<---------------cut here---------------start------------->8---
update public.brintest set byteacol = null, charcol =
public.brintest.charcol, int2col = null, int4col =
public.brintest.int4col, textcol = public.brintest.textcol, oidcol =
cast(coalesce(cast(coalesce(null, public.brintest.oidcol) as oid),
pg_catalog.pg_my_temp_schema()) as oid), tidcol =
public.brintest.tidcol, float8col = public.brintest.float8col,
macaddrcol = null, cidrcol = public.brintest.cidrcol, datecol =
public.brintest.datecol, timecol = public.brintest.timecol,
timestamptzcol = pg_catalog.clock_timestamp(), intervalcol =
public.brintest.intervalcol, timetzcol = public.brintest.timetzcol,
bitcol = public.brintest.bitcol, varbitcol =
public.brintest.varbitcol, uuidcol = null returning
public.brintest.byteacol as c0;
--8<---------------cut here---------------end--------------->8---

Core was generated by `postgres: smith regression [local] UPDATE '.
Program terminated with signal SIGABRT, Aborted.
#0 0x00007fd2cda67067 in __GI_raise (sig=sig(at)entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0 0x00007fd2cda67067 in __GI_raise (sig=sig(at)entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1 0x00007fd2cda68448 in __GI_abort () at abort.c:89
#2 0x00000000007ec969 in errfinish (dummy=dummy(at)entry=0) at elog.c:557
#3 0x00000000007f011c in elog_finish (elevel=elevel(at)entry=20, fmt=fmt(at)entry=0x82ca8f "failed to add BRIN tuple") at elog.c:1378
#4 0x0000000000470618 in brin_doupdate (idxrel=0x101f4c0, pagesPerRange=1, revmap=0x10d20e50, heapBlk=8, oldbuf=2878, oldoff=9, origtup=0x10d864a8, origsz=6144, newtup=0x5328a88, newsz=6144, samepage=1 '\001') at brin_pageops.c:184
#5 0x000000000046e5bb in brininsert (idxRel=0x101f4c0, values=0x211b, nulls=0x6 <error: Cannot access memory at address 0x6>, heaptid=0xffffffffffffffff, heapRel=0x7fd2ce6fd700, checkUnique=UNIQUE_CHECK_NO) at brin.c:244
#6 0x00000000005d887f in ExecInsertIndexTuples (slot=0xe92a560, tupleid=0x10d21084, estate=0x9ed8a68, noDupErr=0 '\000', specConflict=0x0, arbiterIndexes=0x0) at execIndexing.c:383
#7 0x00000000005f74d5 in ExecUpdate (tupleid=0x7ffe11ea74a0, oldtuple=0x211b, slot=0xe92a560, planSlot=0xffffffffffffffff, epqstate=0x7fd2ce6fd700, estate=0x9ed8a68, canSetTag=1 '\001') at nodeModifyTable.c:1015
#8 0x00000000005f7b6c in ExecModifyTable (node=0x9ed8d28) at nodeModifyTable.c:1501
#9 0x00000000005dd5d8 in ExecProcNode (node=node(at)entry=0x9ed8d28) at execProcnode.c:396
#10 0x00000000005d962f in ExecutePlan (dest=0xde86040, direction=<optimized out>, numberTuples=0, sendTuples=<optimized out>, operation=CMD_UPDATE, use_parallel_mode=<optimized out>, planstate=0x9ed8d28, estate=0x9ed8a68) at execMain.c:1567
#11 standard_ExecutorRun (queryDesc=0xde860d8, direction=<optimized out>, count=0) at execMain.c:338
#12 0x00000000006f74c9 in ProcessQuery (plan=<optimized out>, sourceText=0xd74e88 "update public.brintest[...]", params=0x0, dest=0xde86040, completionTag=0x7ffe11ea7670 "") at pquery.c:185
#13 0x00000000006f775f in PortalRunMulti (portal=portal(at)entry=0xde8abf0, isTopLevel=isTopLevel(at)entry=1 '\001', dest=dest(at)entry=0xde86040, altdest=0xc96680 <donothingDR>, completionTag=completionTag(at)entry=0x7ffe11ea7670 "") at pquery.c:1267
#14 0x00000000006f7a0c in FillPortalStore (portal=portal(at)entry=0xde8abf0, isTopLevel=isTopLevel(at)entry=1 '\001') at pquery.c:1044
#15 0x00000000006f845d in PortalRun (portal=0xde8abf0, count=9223372036854775807, isTopLevel=<optimized out>, dest=0x9ee76b8, altdest=0x9ee76b8, completionTag=0x7ffe11ea7a20 "") at pquery.c:782
#16 0x00000000006f5c63 in exec_simple_query (query_string=<optimized out>) at postgres.c:1094
#17 PostgresMain (argc=233352176, argv=0xe8ad358, dbname=0xcf7508 "regression", username=0xe8ad3b0 "Xӊ\016") at postgres.c:4059
#18 0x000000000046c8b2 in BackendRun (port=0xd1c580) at postmaster.c:4258
#19 BackendStartup (port=0xd1c580) at postmaster.c:3932
#20 ServerLoop () at postmaster.c:1690
#21 0x000000000069081e in PostmasterMain (argc=argc(at)entry=4, argv=argv(at)entry=0xcf64f0) at postmaster.c:1298
#22 0x000000000046d80d in main (argc=4, argv=0xcf64f0) at main.c:228

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Korotkov 2016-05-22 12:24:04 Re: Autovacuum to prevent wraparound tries to consume xid
Previous Message Amit Kapila 2016-05-22 09:39:05 Re: Autovacuum to prevent wraparound tries to consume xid