Re: Postgres Crashing

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(dot)klaver(at)aklaver(dot)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 <tgl(at)sss(dot)pgh(dot)pa(dot)us
> > <mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us>> wrote:
> >
> > Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com
> > <mailto:adrian(dot)klaver(at)aklaver(dot)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(dot)klaver(at)aklaver(dot)com
>