Re: Stack-based tracking of per-node WAL/buffer usage - Mailing list pgsql-hackers

From Zsolt Parragi
Subject Re: Stack-based tracking of per-node WAL/buffer usage
Date
Msg-id CAN4CZFMk10YCixVTnt+uBaUH_BH1R=Er-PnPs2YDBhFjuE3K-Q@mail.gmail.com
Whole thread Raw
In response to Re: Stack-based tracking of per-node WAL/buffer usage  (Lukas Fittl <lukas@fittl.com>)
Responses Re: Stack-based tracking of per-node WAL/buffer usage
List pgsql-hackers
+ instr_stack.stack_space *= 2;
+ instr_stack.entries = repalloc_array(instr_stack.entries,
Instrumentation *, instr_stack.stack_space);

Can't this also cause issues with OOM? repalloc_array failing, but we
already doubled stack_space.
The initialization above uses the same order, but that should be safe
as entries is initially NULL.


+ * 2) Accumulate all instrumentation to the currently active instrumentation,
+ *    so that callers get a complete picture of activity, even after an abort
...
+ if (idx >= 0)
+ {
+ while (instr_stack.stack_size > idx + 1)
+ instr_stack.stack_size--;
+
+ InstrPopStack(instr);
+ }

There seems to be one more bug in this:

1. EXPLAIN ANALYZE fires a trigger
2. The trigger function throws ERROR, InstrStopTrigger never runs
3. ResOwnerReleaseInstrumentation runs but only checks
unfinalized_children, not triggers
4. InstrStopFinalize discards the trigger entry
5. Trigger instrumentation information shows 0



pgsql-hackers by date:

Previous
From: Zsolt Parragi
Date:
Subject: Re: table AM option passing
Next
From: Corey Huinker
Date:
Subject: Re: Return pg_control from pg_backup_stop().