Re: Historic snapshot doesn't track txns committed in BUILDING_SNAPSHOT state

From: Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>
To: cca5507 <cca5507(at)qq(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Historic snapshot doesn't track txns committed in BUILDING_SNAPSHOT state
Date: 2024-08-13 08:11:11
Message-ID: ZrsVH0kxpNF0JR9e@ip-10-97-1-34.eu-west-3.compute.internal
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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&nbsp;XLOG_HEAP2_NEW_CID or&nbsp;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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ilia Evdokimov 2024-08-13 09:40:00 Re: change regexp_substr first argument make tests more easier to understand.
Previous Message Joel Jacobson 2024-08-13 07:50:44 Re: Optimize mul_var() for var1ndigits >= 8