Re: four minor proposals for 9.5

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Vik Fearing <vik(dot)fearing(at)dalibo(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: four minor proposals for 9.5
Date: 2014-03-20 00:26:40
Message-ID: CAFj8pRCWQjbq8Az60gP+QffnvKvf+pF1L7wsmbb8i1UpTfHpsA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2014-03-19 23:31 GMT+01:00 Vik Fearing <vik(dot)fearing(at)dalibo(dot)com>:

> On 03/19/2014 04:34 PM, Pavel Stehule wrote:
> > 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
>
> +1
>
> I even wrote a patch to do this, but it wasn't pretty so I never posted
> it. I would be happy to review yours or revive mine.
>
> > 2. fatal verbose - this patch ensure a verbose log for fatal errors.
> > It simplify a investigation about reasons of error.
>
> +0
>
> > 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.
>
> -1
>
> Also, I can't find any temp_files_limit setting anywhere.
>

any our server serves a about 100 users per seconds. We have system, that
generate relative complex queries, where some Cartesian products are valid
(although we are not happy). This limits removes a few (but real) critical
issues, when we didn't enough free space on disc. After implementation of
this limit we are able to ensure safe long time production with about 20%
free space. In multiuser environment is more safe to kill some queries than
lost your all production.

>
> > 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.
>
> -0
>
> > Do you thinking so these patches can be generally useful?
>
> Yes and no, as scored above.
>
> --
> Vik
>
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2014-03-20 00:28:08 Re: four minor proposals for 9.5
Previous Message Pavel Stehule 2014-03-20 00:19:37 Re: Review: plpgsql.extra_warnings, plpgsql.extra_errors