From: | Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz> |
---|---|
To: | Josh Berkus <josh(at)agliodbs(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: WIP - Add ability to constrain backend temporary file space |
Date: | 2011-02-18 21:50:39 |
Message-ID: | 4D5EE9AF.10903@catalyst.net.nz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 19/02/11 10:38, Josh Berkus wrote:
>
>> To answer the other question, what happens when the limit is exceeded is
>> modeled on statement timeout, i.e query is canceled and a message says
>> why (exceeded temp files size).
> When does this happen? When you try to allocate the file, or when it
> does the original tape sort estimate?
>
> The disadvantage of the former is that the user waited for minutes in
> order to have their query cancelled. The disadvantage of the latter is
> that the estimate isn't remotely accurate.
>
Neither - it checks each write (I think this is pretty cheap - adds two
int and double + operations and a /, > operation to FileWrite). If the
check shows you've written more than the limit, you get canceled. So you
can exceed the limit by 1 buffer size.
Yeah, the disadvantage is that (like statement timeout) it is a 'bottom
of the cliff' type of protection. The advantage is there are no false
positives...
Cheers
Mark
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-02-18 21:59:38 | Re: DropRelFileNodeBuffers API change (was Re: [BUGS] BUG #5599: Vacuum fails due to index corruption issues) |
Previous Message | Bruce Momjian | 2011-02-18 21:50:22 | Re: DropRelFileNodeBuffers API change (was Re: [BUGS] BUG #5599: Vacuum fails due to index corruption issues) |