Re: Should a DB vacuum use up a lot of space ?

Поиск
Список
Период
Сортировка
От Jeff Janes
Тема Re: Should a DB vacuum use up a lot of space ?
Дата
Msg-id CAMkU=1xsjnzej79Gr41whg5q_XVfKp2OF_a3GhHL0A1C5ba-zA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Should a DB vacuum use up a lot of space ?  (Philippe Girolami <philippe.girolami@mosaik.com>)
Список pgsql-general
On Mon, Aug 8, 2016 at 12:08 AM, Philippe Girolami
<philippe.girolami@mosaik.com> wrote:

>>Not understanding; 'the auto-vacuum daemon kicks in and burns through
>>the transactions'.
>>Are you saying it is reclaiming xids for you or using them?
>>If reclaiming that is what is supposed to do and is good thing.
>>Or am I misunderstanding?
> Here is  what the logs show when I do what I described above
>
> 1) I got 7 transactions back in single user mode
> Aug  7 23:40:57 p2 postgres[30376]: [5-1] 2016-08-07 23:40:57 CEST WARNING:  database "public" must be vacuumed
within999893 transactions 
> Aug  7 23:40:57 p2 postgres[30376]: [5-2] 2016-08-07 23:40:57 CEST HINT:  To avoid a database shutdown, execute a
database-wideVACUUM in that database. 

What do you mean by getting 7 back?  'Back' compared to what?  You had
999886 before vacuuming that table?


> 2) I exit single user mode and restart the database

999893 is not the number left before hitting the ordinary stop limit,
it is the number left before your database becomes
corrupted. 999893 is stil past the ordinary stop limit (1,000,000), so
there is no point taking it out of single user mode at this point as
it would already be in shutdown at the time it starts.


> 4) lots of autovacuum failures

9.1.23 (to be released tomorrow-ish) does include a change that might
possibly have helped.


>>    The next question to be asked is; what is creating the transactions and
>>    is the transaction rate 'normal' or is there a possibility you have a
>>    rogue process or rogue processes in action?
> That’s always a possibility but I can’t think of what that would be.

I think you are just misinterpreting what the reported number means,
and there is no mysterious transaction consumption going on at all.

Cheers,

Jeff


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

Предыдущее
От: Adrian Klaver
Дата:
Сообщение: Re: RETURNS TABLE function: ERROR: column reference "word" is ambiguous
Следующее
От: Alexander Farber
Дата:
Сообщение: Re: RETURNS TABLE function: ERROR: column reference "word" is ambiguous