From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org, Himanshu Upadhyaya <upadhyaya(dot)himanshu(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Aleksander Alekseev <aleksander(at)timescale(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: HOT chain validation in verify_heapam() |
Date: | 2022-11-10 02:35:12 |
Message-ID: | CAH2-Wzmq0m+X_CnxkskGp5F0Uzxgo0ZnDBiox2HFSen4M4XoDg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Nov 9, 2022 at 6:10 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> And thinking about it, it'd be quite bad if the horizon worked that way. You can easily construct a workload where every single xid would "skewer" some chain, never allowing the horizon to be raised.
Your whole scenario is one involving a insert of a tuple by XID 10,
which is then updated by XID 5 -- a lower XID. Obviously that's
possible, but it's relatively rare. I have to imagine that the vast
majority of updates affect tuples inserted by an XID before the XID of
the updater.
My use of the term "skewer" was limited to updates that look like
that. So I don't know what you mean about never allowing the horizon
to be raised.
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Regina Obe | 2022-11-10 02:43:43 | Ability to reference other extensions by schema in extension scripts |
Previous Message | Jeff Davis | 2022-11-10 02:23:50 | Re: Refactor to introduce pg_strcoll(). |