| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | pgsql-hackers(at)lists(dot)postgresql(dot)org, Melanie Plageman <melanieplageman(at)gmail(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: All-visible pages with valid prune xid are confusing |
| Date: | 2025-12-02 18:41:06 |
| Message-ID: | E5E41BF8-1515-488A-A65D-6A1CFC716238@anarazel.de |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On December 2, 2025 1:23:57 PM EST, Melanie Plageman <melanieplageman(at)gmail(dot)com> wrote:
>On Tue, Dec 2, 2025 at 12:49 PM Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
>>
>> Hmm. If the page has no prunable tuples left, it makes sense to set
>> pd_prune_xid to InvalidTransactionId to avoid the useless round of
>> pruning. In other cases, it would make sense to set it to some XID so
>> that it gets pruned later. But a standby will only start pruning if it's
>> later promoted to become a primary. At that point, all currently running
>> transactions will be finished (except for prepared transactions).
>
>What about on-access pruning during SELECT queries on a hot standby?
There's no on-access-pruning on the hot standby itself, it'd lead to divergence between primary and standby (and you couldn't WAL log it).
Greetings,
Andres
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Sami Imseih | 2025-12-02 18:41:15 | Re: use LW_SHARED in dsa_get_total_size() |
| Previous Message | Melanie Plageman | 2025-12-02 18:23:57 | Re: All-visible pages with valid prune xid are confusing |