I wrote a few patches, that we use in our production. These patches are small, but I hope, so its can be interesting for upstream:
1. cancel time - we log a execution time cancelled statements
there is a interest
2. fatal verbose - this patch ensure a verbose log for fatal errors. It simplify a investigation about reasons of error.
not too much
3. relation limit - possibility to set session limit for maximum size of relations. Any relation cannot be extended over this limit in session, when this value is higher than zero. Motivation - we use lot of queries like CREATE TABLE AS SELECT .. , and some very big results decreased a disk free space too much. It was high risk in our multi user environment. Motivation is similar like temp_files_limit.
is not a interest
4. track statement lock - we are able to track a locking time for query and print this data in slow query log and auto_explain log. It help to us with lather slow query log analysis.
there is a interest
So I'll prepare a some prototypes in next month for
1. log a execution time for cancelled queries,
2. track a query lock time
When I though about this proposal, I found so our implementation is plus/minus hack, that can works well in GoodData, but can be inconsistent with native postgresql. So in this proposal I'll plan some different than we use, but I hope so it is more consistent with upstream.
So I miss a execution time for cancelled queries. Same time can be interesting for some queries that was from any reasons - temp file limits can stop queries after 5 minutes, some out of memory etc ..
It is not hard to implement printing duration for cancelled queries, but is impossible do it for any kind of exception. But there is way. We can use a "log line prefix" space. Now, there are not a possibility to print duration - so we can introduce a new symbol %D as duration. Same technique I would to use for printing lock time - it can be printing instead symbol %L.
so log entry should to look like
timestamp, duration, locktime ERROR, query was cancelled ....
Anybody can activate or deactivate these features by using %D or %L in log_line_prefix
Comments, notes?
Regards
Pavel
Regards
Pavel
Do you thinking so these patches can be generally useful?