2014-03-20 5:36 GMT+01:00 Amit Kapila <amit.kapil...@gmail.com>: > On Wed, Mar 19, 2014 at 9:04 PM, Pavel Stehule <pavel.steh...@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? >
Exception is 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? > It significantly harder to expect N for LIMIT - there are lot of varlena types, so sometimes you can be too strict, sometimes you can be too tolerant > > > With Regards, > Amit Kapila. > EnterpriseDB: http://www.enterprisedb.com >
