Re: Feedback on getting rid of VACUUM FULL

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Feedback on getting rid of VACUUM FULL
Дата
Msg-id 20363.1253205400@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Feedback on getting rid of VACUUM FULL  (Hannu Krosing <hannu@2ndQuadrant.com>)
Ответы Re: Feedback on getting rid of VACUUM FULL  (Hannu Krosing <hannu@2ndQuadrant.com>)
Список pgsql-hackers
Hannu Krosing <hannu@2ndQuadrant.com> writes:
> On Thu, 2009-09-17 at 12:18 -0400, Tom Lane wrote:
>> Or for an update without having to hold a transaction open.  We have
>> recommended this type of technique in the past:

> If you need real locking, then just define a locked (or locked_by or
> locked_until) column and use that for concurrent edit control

That's pessimistic locking, and it sucks for any number of reasons,
most obviously if your client crashes or otherwise forgets to release
the lock.  The method I was illustrating is specifically meant for
apps that would prefer optimistic locking.

>> Exactly.  The application is typically going to throw a "concurrent
>> update" type of error when this happens, and we don't want magic
>> background operations to cause that.

> Would'nt current VACUUM FULL or CLUSTER cause much more grief in this
> situation ?

Sure, but neither of those are recommended for routine maintenance
during live database operations.  (What you might do during maintenance
windows is a different discussion.)
        regards, tom lane


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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: opportunistic tuple freezing
Следующее
От: "Kevin Grittner"
Дата:
Сообщение: Re: Linux LSB init script