Horton

Re: datfrozenxid > relfrozenxid w/ crash before XLOG_HEAP_INPLACE

Noah Misch <noah@leadboat.com>

View thread View on postgr.es
From: Noah Misch <noah@leadboat.com>
To: "Andrey M. Borodin" <x4mmm@yandex-team.ru>
Cc: pgsql-hackers@postgresql.org
Date: 2024-06-20T15:08:43Z
Lists: pgsql-hackers 
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

Commits

  1. WAL-log inplace update before revealing it to other sessions.

  2. Comment on need to MarkBufferDirty() if omitting DELAY_CHKPT_START.