Hello, Hopefully the following stack trace is more helpful.
Exception thrown at 0x0000000140446403 in postgres.exe: 0xC0000005: Access violation reading location 0xFFFFFFFFFFFFFFF8. occurred > postgres.exe!pfree(void * pointer) Line 1033 C postgres.exe!tts_buffer_heap_clear(TupleTableSlot * slot) Line 653 C [Inline Frame] postgres.exe!ExecClearTuple(TupleTableSlot *) Line 428 C postgres.exe!ExecForceStoreHeapTuple(HeapTupleData * tuple, TupleTableSlot * slot, bool shouldFree) Line 1448 C postgres.exe!ExecBRUpdateTriggers(EState * estate, EPQState * epqstate, ResultRelInfo * relinfo, ItemPointerData * tupleid, HeapTupleData * fdw_trigtuple, TupleTableSlot * newslot) Line 3117 C postgres.exe!ExecUpdate(ModifyTableState * mtstate, ItemPointerData * tupleid, HeapTupleData * oldtuple, TupleTableSlot * slot, TupleTableSlot * planSlot, EPQState * epqstate, EState * estate, bool canSetTag) Line 1072 C postgres.exe!ExecModifyTable(PlanState * pstate) Line 2223 C [Inline Frame] postgres.exe!ExecProcNode(PlanState *) Line 239 C postgres.exe!ExecutePlan(EState * estate, PlanState * planstate, bool use_parallel_mode, CmdType operation, bool sendTuples, unsigned __int64 numberTuples, ScanDirection direction, _DestReceiver * dest, bool execute_once) Line 1652 C postgres.exe!standard_ExecutorRun(QueryDesc * queryDesc, ScanDirection direction, unsigned __int64 count, bool execute_once) Line 378 C postgres.exe!_SPI_pquery(QueryDesc * queryDesc, bool fire_triggers, unsigned __int64 tcount) Line 2523 C postgres.exe!_SPI_execute_plan(_SPI_plan * plan, ParamListInfoData * paramLI, SnapshotData * snapshot, SnapshotData * crosscheck_snapshot, bool read_only, bool fire_triggers, unsigned __int64 tcount) Line 2298 C postgres.exe!SPI_execute_plan_with_paramlist(_SPI_plan * plan, ParamListInfoData * params, bool read_only, long tcount) Line 581 C plpgsql.dll!exec_stmt_execsql(PLpgSQL_execstate * estate, PLpgSQL_stmt_execsql * stmt) Line 4162 C plpgsql.dll!exec_stmt(PLpgSQL_execstate * estate, PLpgSQL_stmt * stmt) Line 2033 C [Inline Frame] plpgsql.dll!exec_stmts(PLpgSQL_execstate * stmts, List *) Line 1924 C plpgsql.dll!exec_stmt_block(PLpgSQL_execstate * estate, PLpgSQL_stmt_block * block) Line 1865 C plpgsql.dll!exec_stmt(PLpgSQL_execstate * estate, PLpgSQL_stmt * stmt) Line 1957 C plpgsql.dll!plpgsql_exec_function(PLpgSQL_function * func, FunctionCallInfoBaseData * fcinfo, EState * simple_eval_estate, bool atomic) Line 590 C plpgsql.dll!plpgsql_call_handler(FunctionCallInfoBaseData * fcinfo) Line 267 C postgres.exe!ExecInterpExpr(ExprState * state, ExprContext * econtext, bool * isnull) Line 626 C [Inline Frame] postgres.exe!ExecEvalExprSwitchContext(ExprState *) Line 307 C postgres.exe!ExecProject(ProjectionInfo * projInfo) Line 351 C [Inline Frame] postgres.exe!ExecProcNode(PlanState *) Line 239 C postgres.exe!ExecutePlan(EState * estate, PlanState * planstate, bool use_parallel_mode, CmdType operation, bool sendTuples, unsigned __int64 numberTuples, ScanDirection direction, _DestReceiver * dest, bool execute_once) Line 1652 C postgres.exe!standard_ExecutorRun(QueryDesc * queryDesc, ScanDirection direction, unsigned __int64 count, bool execute_once) Line 378 C postgres.exe!PortalRunSelect(PortalData * portal, bool forward, long count, _DestReceiver * dest) Line 931 C postgres.exe!PortalRun(PortalData * portal, long count, bool isTopLevel, bool run_once, _DestReceiver * dest, _DestReceiver * altdest, char * completionTag) Line 777 C postgres.exe!exec_execute_message(const char * portal_name, long max_rows) Line 2098 C postgres.exe!PostgresMain(int argc, char * * argv, const char * dbname, const char * username) Line 4299 C postgres.exe!BackendRun(Port * port) Line 4432 C postgres.exe!SubPostmasterMain(int argc, char * * argv) Line 4955 C postgres.exe!main(int argc, char * * argv) Line 216 C [External Code] On Tue, Feb 4, 2020 at 11:40 AM Adrian Klaver <adrian.kla...@aklaver.com> wrote: > On 2/4/20 6:20 AM, Doug Roberts wrote: > >> So how did containers_reset_recirc() come to clash with > >> containers_add_update()? > > > > They are clashing because another portion of our system is running and > > updating containers. The reset recirc function was run at the same time > > to see how our system and the database would handle it. > > So does your system have the things Tom mentioned below?: > > "The known bugs in that area > require either before-row-update triggers on the table, or > child tables (either partitioning or traditional inheritance). > So I wonder what the schema of table "containers" looks like." > > > > > The recirc string is formatted like 2000=3,1000=6,5000=0. So the reset > > recirc function with take a UID (1000 for example) and use that to > > remove 1000=x from all of the recirc counts for all of the containers > > that have 1000=x. > > > > We are currently using PG 12.0. > > > > Thanks, > > > > Doug > > > > On Mon, Feb 3, 2020 at 6:21 PM Tom Lane <t...@sss.pgh.pa.us > > <mailto:t...@sss.pgh.pa.us>> wrote: > > > > Adrian Klaver <adrian.kla...@aklaver.com > > <mailto:adrian.kla...@aklaver.com>> writes: > > > Please reply to list also. > > > > > On 2/3/20 2:18 PM, Doug Roberts wrote: > > >> Here is what the reset recirc function is doing. > > >> ... > > >> UPDATE containers > > >> ... > > > > > So how did containers_reset_recirc() come to clash with > > > containers_add_update()? > > > > If this is PG 12.0 or 12.1, a likely theory is that this is an > > EvalPlanQual bug (which'd be triggered during concurrent updates > > of the same row in the table, so that squares with the observation > > that locking the table prevents it). The known bugs in that area > > require either before-row-update triggers on the table, or > > child tables (either partitioning or traditional inheritance). > > So I wonder what the schema of table "containers" looks like. > > > > Or you could have hit some new bug ... but there's not enough > > info here to diagnose. > > > > regards, tom lane > > > > > -- > Adrian Klaver > adrian.kla...@aklaver.com >
