Re: All-visible pages with valid prune xid are confusing

From: Andres Freund <andres(at)anarazel(dot)de>
To: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Cc: Melanie Plageman <melanieplageman(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: All-visible pages with valid prune xid are confusing
Date: 2025-12-02 19:49:13
Message-ID: xaknzmkoz2nudbefkvw2kuaxew5pjexebzwh3ji2d4bx6a5uqa@iqgrggdlgb77
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2025-12-02 21:39:42 +0200, Heikki Linnakangas wrote:
> On 02/12/2025 21:13, Melanie Plageman wrote:
> > In terms of finding some XID to set it to, could we do what updates
> > and deletes do and use the XLogRecord->xl_xid?
>
> A prune record can have XLogRecord->xl_xid == InvalidTransactionId, if the
> transaction hasn't been assigned a transaction ID yet. I think
> ReadNextTransactionId() - 1 would work. (Using TransactionIdRetreat rather
> than plain - 1, of course)

I think it'd be preferrable if we just made the records large enough to
maintain the same pd_prune_xid on the standby as on the primary. The closer
the pages are on primary & standby the better, any allowed divergence makes it
harder to find bugs imo. In comparison to the space the relevant records use,
it doesn't seem like including an accurate prune xid would take a lot of
space?

Greetings,

Andres

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2025-12-02 20:00:39 Re: Remove useless pointer advance in StatsShmemInit()
Previous Message Heikki Linnakangas 2025-12-02 19:39:42 Re: All-visible pages with valid prune xid are confusing