Re: four minor proposals for 9.5 - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: four minor proposals for 9.5
Date
Msg-id CAA4eK1Jftc-f8ro7G_ipGJ7bZUqf2MGYcK7-Ebx820ji6rnT-g@mail.gmail.com
Whole thread Raw
In response to four minor proposals for 9.5  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: four minor proposals for 9.5  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers
On Wed, Mar 19, 2014 at 9:04 PM, Pavel Stehule <pavel.stehule@gmail.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



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: issue log message to suggest VACUUM FULL if a table is nearly empty
Next
From: Kyotaro HORIGUCHI
Date:
Subject: Re: Archive recovery won't be completed on some situation.