On Thu, Jun 20, 2024 at 12:17:44PM +0500, Andrey M. Borodin wrote:
> On 20 Jun 2024, at 06:29, Noah Misch <noah@leadboat.com> wrote:
> > This resolves the last inplace update defect known to me.
>
> That’s a huge amount of work, thank you!
>
> Do I get it right, that inplace updates are catalog-specific and some other OOM corruptions [0] and Standby
corruptions[1] are not related to this fix. Bot cases we observed on regular tables.
In core code, inplace updates are specific to pg_class and pg_database.
Adding PGXN modules, only the citus extension uses them on some other table.
[0] definitely looks unrelated.
> Or that might be effect of vacuum deepening corruption after observing wrong datfrozenxid?
Wrong datfrozenxid can cause premature clog truncation, which can cause "could
not access status of transaction". While $SUBJECT could cause that, I think
it would happen on both primary and standby. [1] seems to be about a standby
lacking clog present on the primary, which is unrelated.
> [0]
https://www.postgresql.org/message-id/flat/67EADE8F-AEA6-4B73-8E38-A69E5D48BAFE%40yandex-team.ru#1266dd8b898ba02686c2911e0a50ab47
> [1]
https://www.postgresql.org/message-id/flat/CAFj8pRBEFMxxFSCVOSi-4n0jHzSaxh6Ze_cZid5eG%3Dtsnn49-A%40mail.gmail.com