Re: relfrozenxid may disagree with row XIDs after 1ccc1e05ae

Поиск
Список
Период
Сортировка
От Bowen Shi
Тема Re: relfrozenxid may disagree with row XIDs after 1ccc1e05ae
Дата
Msg-id CAM_vCufwibz7iuKOuSc29-01g4vxde5dBp+ExJ-qQABwHqGZVg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: relfrozenxid may disagree with row XIDs after 1ccc1e05ae  (Melanie Plageman <melanieplageman@gmail.com>)
Ответы Re: relfrozenxid may disagree with row XIDs after 1ccc1e05ae
Список pgsql-bugs
Hi,

On Thu, May 23, 2024 at 12:57 AM Melanie Plageman <melanieplageman@gmail.com> wrote:
One option is to add the logic in fix_hang_15.patch to master as well
(always remove tuples older than OldestXmin). This addresses your
concern about gaining confidence in a single solution.

However, I can see how removing more tuples could be concerning. In
the case that the horizon moves backwards because of a standby
reconnecting, I think the worst case is that removing that tuple
causes a recovery conflict on the standby (depending on the value of
max_standby_streaming_delay et al).

I'm confused about this part. The comment above OldestXmin says:
/*
 * OldestXmin is the Xid below which tuples deleted by any xact (that
 * committed) should be considered DEAD, not just RECENTLY_DEAD.
 */
With the fix_hang_15 patch, why is there a risk here when we use Oldestxmin to judge whether a tuple could be moved?

I think the keypoint is: OldestXmin and VisTest, which one is more accurate when we judge to remove the tuple.



--
Regards
Bowen Shi

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

Предыдущее
От: Bowen Shi
Дата:
Сообщение: Re: relfrozenxid may disagree with row XIDs after 1ccc1e05ae
Следующее
От: Waka Ranai
Дата:
Сообщение: Re: Bug report - pg_upgrade tool seems to have a race condition when trying to delete a pg_wal file