Re: four minor proposals for 9.5

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: four minor proposals for 9.5
Date: 2014-03-20 04:36:10
Message-ID: CAA4eK1Jftc-f8ro7G_ipGJ7bZUqf2MGYcK7-Ebx820ji6rnT-g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Mar 19, 2014 at 9:04 PM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> 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
>
> 2. fatal verbose - this patch ensure a verbose log for fatal errors. It
> simplify a investigation about reasons of error.
>
> 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.

So if there is error on reaching max threshold size, won't it loose all data or
is that expected?

Also I think it might not be applicable for all table inserts, as normally
checkpointer/bgrwriter flushes data, so you might not be able to estimate
size immediately when your SQL statement is executing.

Won't it better to have LIMIT Rows in Select statement or generically
have table level option for Max Rows?

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro HORIGUCHI 2014-03-20 06:17:55 Re: Archive recovery won't be completed on some situation.
Previous Message Amit Kapila 2014-03-20 03:44:58 Re: issue log message to suggest VACUUM FULL if a table is nearly empty