Re: Hot Backup with rsync fails at pg_clog if under load

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Hot Backup with rsync fails at pg_clog if under load
Дата
Msg-id 27827.1319724793@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Hot Backup with rsync fails at pg_clog if under load  (Simon Riggs <simon@2ndQuadrant.com>)
Ответы Re: Hot Backup with rsync fails at pg_clog if under load
Список pgsql-hackers
Simon Riggs <simon@2ndQuadrant.com> writes:
> On Thu, Oct 27, 2011 at 12:36 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> On Thu, Oct 27, 2011 at 5:37 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>>> It's much easier to understand that StartupCLOG() is actually a no-op
>>> and that we need to trim the clog at the end of recovery in all cases.

>> If it's a no-op, why have it at all?

> It is a no-op for exactly the same reason other similar functions are
> no-ops - it used to do something but now does not.

> Anyone seeing StartupSubtrans and StartupMultiXact but no StartupClog
> will immediately ask "why?".

I think it's a good point that StartupCLog doesn't exist in a vacuum
but should be parallel to the init functions for the other SLRU modules.
So at this point I think I agree with Simon's approach.  However, the
obvious next question is whether those other modules don't need to be
changed also, and if not why not.

Another issue is that if StartupCLog is left as a no-op, what will
happen if someone mistakenly tries to access clog before the trim
function is called?  It would be a good idea to make sure that such
a thing results in an easily-identifiable failure.
        regards, tom lane


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

Предыдущее
От: Florian Pflug
Дата:
Сообщение: Re: Hot Backup with rsync fails at pg_clog if under load
Следующее
От: Magnus Hagander
Дата:
Сообщение: Re: Your review of pg_receivexlog/pg_basebackup