Date: Sat, 14 Mar 2020 14:26:57 -0700
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Daniel WM <dwilches@gmail.com>, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #16293: postgres segfaults and returns SQLSTATE 08006
Message-ID: <20200314212657.jnvxfocyd5redf3p@alap3.anarazel.de>
References: <16293-26f5777d10143a66@postgresql.org>
 <28203.1583878791@sss.pgh.pa.us>
 <CAEbtaO3wTbx-DOh+B9UfNpoS2N4nQm25Y1DLrNNN_U1-8qNnqg@mail.gmail.com>
 <CAEbtaO39qxx7GX=u8j02y5K2eyVGT8gyCOLHS2KNENQS=w_D7Q@mail.gmail.com>
 <21088.1584220864@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <21088.1584220864@sss.pgh.pa.us>
Precedence: bulk

Hi,

On 2020-03-14 17:21:04 -0400, Tom Lane wrote:
> Daniel WM <dwilches@gmail.com> writes:
> > I have finally isolated the issue and I have a set of steps that reliably
> > cause the segfault:
> 
> Interesting.  I do *not* see a crash in v12 or HEAD, but v11 gives
> me an assertion failure:
> 
> TRAP: FailedAssertion("!(!slot->tts_fixedTupleDescriptor)", File: "execTuples.c", Line: 284)
> 2020-03-14 17:16:06.626 EDT [1101] LOG:  server process (PID 20822) was terminated by signal 6: Aborted
> 2020-03-14 17:16:06.626 EDT [1101] DETAIL:  Failed process was running: INSERT INTO parent_table VALUES ('2020-02-02 01:00:00+00:00', 'f');
> 
> here:
> 
> #3  0x000000000063ef45 in ExecSetSlotDescriptor (slot=0x1cf4060, 
>     tupdesc=0x7f903a2dd0f8) at execTuples.c:284
> #4  0x00000000006360eb in ExecConstraints (resultRelInfo=0x1cf47b8, 
>     slot=0x1cf4060, estate=0x1cf3778) at execMain.c:2062
> #5  0x000000000065a44d in ExecInsert (mtstate=0x1cf3ae0, slot=0x1cf4060, 
>     planSlot=0x1cf4060, estate=0x1cf3778, canSetTag=true)
>     at nodeModifyTable.c:398
> #6  0x000000000065b80b in ExecModifyTable (pstate=<value optimized out>)
>     at nodeModifyTable.c:2159
> #7  0x0000000000636c27 in ExecProcNode (queryDesc=0x1ce51e8, 
>     direction=<value optimized out>, count=0, execute_once=224)
>     at ../../../src/include/executor/executor.h:247
> #8  ExecutePlan (queryDesc=0x1ce51e8, direction=<value optimized out>, 
>     count=0, execute_once=224) at execMain.c:1723
> #9  standard_ExecutorRun (queryDesc=0x1ce51e8, 
>     direction=<value optimized out>, count=0, execute_once=224)
> 
> So this looks like something to do with Andres' tupletableslot work.

Interesting. There wasn't that much in v11. It's not the general rework,
but just the allocation of the descriptor together slot when the
descriptor is known at creation time - or a conflict with concurrent
partitioning work.  It's plausible that enough changed in master for
that to not be a problem anymore.

Looking.

Greetings,

Andres Freund