Re: [DOCS] pg_total_relation_size() and CHECKPOINT

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [DOCS] pg_total_relation_size() and CHECKPOINT
Дата
Msg-id 21044.1206580136@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [DOCS] pg_total_relation_size() and CHECKPOINT  (Andrew Dunstan <andrew@dunslane.net>)
Ответы Re: [DOCS] pg_total_relation_size() and CHECKPOINT  (Andrew Dunstan <andrew@dunslane.net>)
Re: [DOCS] pg_total_relation_size() and CHECKPOINT  (Andrew Dunstan <andrew@dunslane.net>)
Список pgsql-hackers
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.
        regards, tom lane


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

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