Re: [DOCS] pg_total_relation_size() and CHECKPOINT

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: [DOCS] pg_total_relation_size() and CHECKPOINT
Дата
Msg-id 47EB0850.1050805@dunslane.net
обсуждение исходный текст
Ответ на Re: [DOCS] pg_total_relation_size() and CHECKPOINT  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [DOCS] pg_total_relation_size() and CHECKPOINT  (Alvaro Herrera <alvherre@commandprompt.com>)
Список pgsql-hackers

Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>   
>> Tom Lane wrote:
>>     
>>>> The real question here is whether Windows' stat() is telling the truth
>>>> about how much filesystem space has actually been allocated to a file.
>>>>         
>>> One thing that would be good is just to see who else can reproduce
>>> the original observation:
>>> http://archives.postgresql.org/pgsql-docs/2008-03/msg00041.php
>>>       
>
>   
>> I have reproduced it in XP-Pro/SP2 running in a VMWare machine on an FC6 
>> host.
>>     
>
> OK, so the next question is do we really have an issue, or is this just
> an observational artifact?  What I'd try is deliberately running the
> machine out of disk space with a long series of inserts, and then see
> whether subsequent checkpoint attempts fail due to ENOSPC errors while
> trying to write out dirty buffers.
>
> To avoid conflating this effect with anything else, it'd be best if you
> could put the DB on its own small partition, and *not* put pg_xlog
> there.
>
>     
>   

I'm working on this (thank goodness for junctions). Maybe we shopuld 
look at providing a config setting for pg_xlog.

cheers

andrew


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [DOCS] pg_total_relation_size() and CHECKPOINT
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: [DOCS] pg_total_relation_size() and CHECKPOINT