Re: Historic snapshot doesn't track txns committed in BUILDING_SNAPSHOT state - Mailing list pgsql-hackers

From Bertrand Drouvot
Subject Re: Historic snapshot doesn't track txns committed in BUILDING_SNAPSHOT state
Date
Msg-id ZrsVH0kxpNF0JR9e@ip-10-97-1-34.eu-west-3.compute.internal
Whole thread Raw
In response to Re: Historic snapshot doesn't track txns committed in BUILDING_SNAPSHOT state  ("cca5507" <cca5507@qq.com>)
Responses Re: Historic snapshot doesn't track txns committed in BUILDING_SNAPSHOT state
List pgsql-hackers
Hi,

On Tue, Aug 13, 2024 at 03:32:42PM +0800, cca5507 wrote:
> Hi,
> 
> - I re-read your comments in [0] and it looks like you've concern about
> - the 2 "if" I'm proposing above and the fast forward handling. Is that the case
> - or is your fast forward concern unrelated to my proposals?
> 
> 
> 
> In your proposals, we will just return when fast forward. But I think we need
> handle XLOG_HEAP2_NEW_CID or XLOG_HEAP_INPLACE even if we are fast
> forwarding as it decides whether the snapshot will track the transaction or not.
> 
> 
> During fast forward, if there is a transaction that generates XLOG_HEAP2_NEW_CID
> but no XLOG_XACT_INVALIDATIONS(I'm not sure), the snapshot won't track this
> transaction in your proposals, I think it's wrong from a build snapshot perspective.
> 
> 
> Although we don't decode anything during fast forward, the snapshot might be
> serialized to disk when CONSISTENT, it would be better to keep the snapshot correct.

IIUC your "fast forward" concern is not related to this particular thread but you
think it's already an issue on the master branch (outside of the BUILDING_SNAPSHOT
handling we are discussing here), is that correct? (that's also what your coding
changes makes me think of). If so, I'd suggest to open a dedicated thread for that
particular "fast forward" point and do the coding in the current thread as if the
fast forward is not an issue.

Does that make sense?

> 
> - Not sure what happened but it looks like your reply in [0] is not part of the
> - initial thread [1], but created a new thread instead, making the whole
> - conversation difficult to follow.
> 
> I'm not sure what happened but I attach the new thread to the CF:

Unfortunately your last reply did start a new email thread again.

Regards,

-- 
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com



pgsql-hackers by date:

Previous
From: "Joel Jacobson"
Date:
Subject: Re: Optimize mul_var() for var1ndigits >= 8
Next
From: Ilia Evdokimov
Date:
Subject: Re: change regexp_substr first argument make tests more easier to understand.