2011/6/15 Mark Kirkwood <mark.kirkw...@catalyst.net.nz>: > On 15/06/11 02:52, Cédric Villemain wrote: >> >> 2011/6/3 Mark Kirkwood<mark.kirkw...@catalyst.net.nz>: >>> >>> Corrected v4 patch with the test files, for completeness. Note that >>> discussion has moved on and there will be a v5 :-) >>> >> Mark, can you submit your updated patch ? >> > > Thanks for the reminder! Here is v5. The changes are:
I have issues applying it. Please can you remove trailing space? Also, you can generate a cool patch like this : get git-external-diff from postgres/src/tools to /usr/lib/git-core/ chmod +x it export GIT_EXTERNAL_DIFF=git-external-diff git format-patch --ext-diff origin my log: $ git apply temp-files-v5.patch temp-files-v5.patch:22: trailing whitespace. defaults to unlimited (<literal>-1</>). Values larger than zero temp-files-v5.patch:23: trailing whitespace. constraint the temporary file space usage to be that number of temp-files-v5.patch:28: trailing whitespace. the total space used by all the files produced by one backend is temp-files-v5.patch:35: trailing whitespace. constrain disk space used for temporary table storage. However if temp-files-v5.patch:105: trailing whitespace. /* error: patch failed: src/backend/storage/file/fd.c:132 error: src/backend/storage/file/fd.c: patch does not apply error: src/test/regress/expected/resource.out: No such file or directory error: src/test/regress/sql/resource.sql: No such file or directory > > - guc is called temp_file_limit, which seems like the best choice to date > :-) > - removed code to do with truncating files, as after testing I agree with > you that temp work files don't seem to get truncated. > > I have not done anything about the business on units - so we are in KB still > - there is no MB unit avaiable in the code as yet - I'm not sure we need one > at this point, as most folk who use this feature will find 4096GB a big > enough *per backend* limit. Obviously it might be a good investment to plan > to have MB, and GB as possible guc units too. Maybe this could be a separate > piece of work since any *other* resource limiters we add might find it > convenient to have these available? > > Cheers > > Mark > -- Cédric Villemain 2ndQuadrant http://2ndQuadrant.fr/ PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers