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 CAN4CZFOUTHdXuEAwrST8ueDxGJRe69zVgeVAY0osTjVkRZi_Lw@mail.gmail.com
Whole thread Raw
In response to Re: Stack-based tracking of per-node WAL/buffer usage  (Heikki Linnakangas <hlinnaka@iki.fi>)
Responses Re: Stack-based tracking of per-node WAL/buffer usage
List pgsql-hackers
> I'm looking at this finalize at resowner part of this patch, and this
> maybe a stupid question, but:
>
> Why does the instrumentation need to be "finalized" on abort? If you run
> EXPLAIN ANALYZE and the query aborts, you don't get to see the stats anyway.

The pg_session_buffer_usage in 0009 makes the information available, I
was able to see the issue with failing triggers with that. Even if
that part doesn't get committed in the end, a 3rd party extension
could still implement the same thing, and notice the missing
statistics. (And maybe it is useful to see some statistics about
failing queries?)



pgsql-hackers by date:

Previous
From: Sami Imseih
Date:
Subject: Re: another autovacuum scheduling thread
Next
From: shihao zhong
Date:
Subject: [Patch] New pg_stat_tablespace view