2011/6/15 Mark Kirkwood <mark.kirkwood@catalyst.net.nz>:
> On 15/06/11 02:52, Cédric Villemain wrote:
>>
>> 2011/6/3 Mark Kirkwood<mark.kirkwood@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
