| 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
| 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 |