Re: four minor proposals for 9.5

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: four minor proposals for 9.5
Дата
Msg-id CAA4eK1Jftc-f8ro7G_ipGJ7bZUqf2MGYcK7-Ebx820ji6rnT-g@mail.gmail.com
обсуждение исходный текст
Ответ на four minor proposals for 9.5  (Pavel Stehule <pavel.stehule@gmail.com>)
Ответы Re: four minor proposals for 9.5  (Pavel Stehule <pavel.stehule@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: issue log message to suggest VACUUM FULL if a table is nearly empty
Следующее
От: Kyotaro HORIGUCHI
Дата:
Сообщение: Re: Archive recovery won't be completed on some situation.