From: | cca5507 <cca5507(at)qq(dot)com> |
---|---|
To: | Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(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-12 08:34:25 |
Message-ID: | tencent_8DEC9842690A9B6AFD52D4659EF0700E9409@qq.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
4, 5 ===
> if (SnapBuildCurrentState(builder) < SNAPBUILD_BUILDING_SNAPSHOT ||
> (SnapBuildCurrentState(builder) == SNAPBUILD_BUILDING_SNAPSHOT && info != XLOG_HEAP_INPLACE) ||
> ctx->fast_forward)
> return;
I think during fast forward, we also need handle the xlog that marks a transaction
as catalog modifying, or the snapshot might lose some transactions?
> That way we'd still rely on what's being done in the XLOG_HEAP_INPLACE case
+ if (SnapBuildCurrentState(builder) >= SNAPBUILD_BUILDING_SNAPSHOT)
+ {
+ /* Currently only XLOG_HEAP_INPLACE means a catalog modifying */
+ if (info == XLOG_HEAP_INPLACE && TransactionIdIsValid(xid))
+ ReorderBufferXidSetCatalogChanges(ctx->reorder, xid, buf->origptr);
+ }
We only call ReorderBufferXidSetCatalogChanges() for the xlog that marks a transaction as catalog
modifying, and we don't care about the other steps being done in the xlog, so I think the current
approach is ok.
--
Regards,
ChangAo Chen
From | Date | Subject | |
---|---|---|---|
Next Message | John Naylor | 2024-08-12 08:34:26 | Re: Linux likely() unlikely() for PostgreSQL |
Previous Message | Peter Eisentraut | 2024-08-12 07:44:02 | Re: Don't overwrite scan key in systable_beginscan() |