2014-03-27 17:56 GMT+01:00 Pavel Stehule <pavel.steh...@gmail.com>:

> Hello
>
> After week, I can to evaluate a community reflection:
>
>
> 2014-03-19 16:34 GMT+01:00 Pavel Stehule <pavel.steh...@gmail.com>:
>
> Hello
>>
>> 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?
>>
>> Regards
>>
>> Pavel
>>
>
>

Reply via email to