From: | Peter Geoghegan <pg(at)heroku(dot)com> |
---|---|
To: | Peter Tripp <peter(at)chartio(dot)com> |
Cc: | Virendra Negi <virendra(at)idyllic-software(dot)com>, pgsql-bugs <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: BUG #14150: Attempted to delete invisible tuple |
Date: | 2016-06-28 01:41:55 |
Message-ID: | CAM3SWZT0-XQv5R1vR+Ji5V6F-GOjJbUXKV2owCaPTGhJujY0HA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Mon, Jun 13, 2016 at 4:52 PM, Peter Tripp <peter(at)chartio(dot)com> wrote:
> Thank you for your assistance in tracking this down Peter G. My apologies
> for the delayed reply, I've was out sick in days following my original post.
So, I've managed to create a test case that triggers this bug
reliably, without involving VACUUM, or foreign keys.
I have a test case involving pgbench and some conflicting jsonb-based
UPSERT statements with large, toastable jsonb datums. I did hand tune
the data distributions and number of clients a little to get the
problem to reproduce. I was attempting to roughly simulate a
customer's problem report, having failed with simpler cases that
involved upserting with TOAST (I approximated the data distributions
involved, and so on).
Here is a backtrace following promoting the "attempted to delete
invisible tuple" elog's elevel to PANIC:
(gdb) bt
#0 0x00007fbdbe2be418 in __GI_raise (sig=sig(at)entry=6) at
../sysdeps/unix/sysv/linux/raise.c:54
#1 0x00007fbdbe2c001a in __GI_abort () at abort.c:89
#2 0x00000000007dd674 in errfinish (dummy=<optimized out>) at elog.c:557
#3 0x00000000004a4e84 in heap_delete
(relation=relation(at)entry=0x7fbdbf9aab38, tid=tid(at)entry=0x156e9bc,
cid=0, crosscheck=crosscheck(at)entry=0x0, wait=wait(at)entry=1 '\001',
hufd=hufd(at)entry=0x7ffdccd28630) at heapam.c:3015
#4 0x00000000004a4f03 in simple_heap_delete
(relation=relation(at)entry=0x7fbdbf9aab38, tid=0x156e9bc) at
heapam.c:3378
#5 0x00000000004ae224 in toast_delete_datum (value=<optimized out>,
rel=0x7fbdbf9a5250) at tuptoaster.c:1706
#6 0x00000000004aee17 in toast_delete (rel=rel(at)entry=0x7fbdbf9a5250,
oldtup=oldtup(at)entry=0x7ffdccd2bf90) at tuptoaster.c:509
#7 0x00000000004a7cbf in heap_abort_speculative
(relation=0x7fbdbf9a5250, tuple=0x15b87b0) at heapam.c:6003
#8 0x00000000005e5624 in ExecInsert (canSetTag=1 '\001',
estate=0x156d0d0, onconflict=ONCONFLICT_UPDATE,
arbiterIndexes=0x15aa460, planSlot=0x156d7d8, slot=0x156d7d8,
mtstate=0x156d320) at nodeModifyTable.c:443
#9 ExecModifyTable (node=0x156d320) at nodeModifyTable.c:1496
Sure enough, the error code path goes through simple_heap_delete(),
and this is related to TOAST. It usually takes no more than 5 seconds
for the test case to show the problem. I'll go work on a proper
diagnosis now.
Thanks for your help, Peter.
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2016-06-28 03:28:03 | Re: BUG #14150: Attempted to delete invisible tuple |
Previous Message | Michael Paquier | 2016-06-28 00:58:11 | Re: BUG #13907: Restore materialized view throw permission denied |