Re: Rework the way multixact truncations work

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Rework the way multixact truncations work
Дата
Msg-id 20150927192553.GA27495@awork2.anarazel.de
обсуждение исходный текст
Ответ на Re: Rework the way multixact truncations work  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Ответы Re: Rework the way multixact truncations work  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Список pgsql-hackers
On 2015-09-27 14:21:08 -0500, Jim Nasby wrote:
> IMHO doing just a log of something this serious; it should at least be a
> WARNING.

In postgres LOG, somewhat confusingly, is more severe than WARNING.

> I think the concern about upgrading a replica before the master is valid; is
> there some way we could over-ride a PANIC when that's exactly what someone
> is trying to do? Check for a special file maybe?

I don't understand this concern - that's just the situation we have in
all released branches today.

> +    bool        sawTruncationInCkptCycle;
> What happens if someone downgrades the master, back to a version that no
> longer logs truncation? (I don't think assuming that the replica will need
> to restart if that happens is a safe bet...)

It'll just to do legacy truncation again - without a restart on the
standby required.

> -    if (MultiXactIdPrecedes(oldestMXact, earliest))
> +    /* If there's nothing to remove, we can bail out early. */
> +    if (MultiXactIdPrecedes(oldestMulti, earliest))
>      {
> -        DetermineSafeOldestOffset(oldestMXact);
> +        LWLockRelease(MultiXactTruncationLock);
> If/when this is backpatched, would it be safer to just leave this alone?

What do you mean? This can't just isolated be left alone?



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

Предыдущее
От: Jim Nasby
Дата:
Сообщение: Re: Rework the way multixact truncations work
Следующее
От: Gavin Wahl
Дата:
Сообщение: BRIN indexes for MAX, MIN, ORDER BY?