> On Jan 31, 2017, at 3:54 PM, Simon Slavin wrote:
>
> On 31 Jan 2017, at 10:40pm, Warren Young wrote:
>
>> On Jan 31, 2017, at 2:03 PM, Ward WIllats wrote:
>>
>>> the delete sometimes (very rarely) fails with a 13 "disk or
On 31 Jan 2017, at 10:40pm, Warren Young wrote:
> On Jan 31, 2017, at 2:03 PM, Ward WIllats wrote:
>
>> the delete sometimes (very rarely) fails with a 13 "disk or database full"
>> error. I assume because the purger is late to the party and it
On Jan 31, 2017, at 2:03 PM, Ward WIllats wrote:
>
> the delete sometimes (very rarely) fails with a 13 "disk or database full"
> error. I assume because the purger is late to the party and it needs pages in
> the WAL to be able to rollback if necessary.
Is there an
On 1/31/17, Ward WIllats wrote:
> 1. The operational assumption (delete need pages) I've asserted here is
> correct, and
That is correct. While the delete is underway, you need to have both
the old and new content of every modified database page stored on
disk, in case
Hello.
We have an embedded system out in the wild with a DB in WALL mode that we set a
max_pages value on to keep its size constrained. The system is more or less a
data logger. We run a "purger" thread at intervals to DELETE records when it
discovers free space is running below a threshold.
5 matches
Mail list logo