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 по дате отправления: