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

From cca5507
Subject Re: Historic snapshot doesn't track txns committed in BUILDING_SNAPSHOT state
Date
Msg-id tencent_8DEC9842690A9B6AFD52D4659EF0700E9409@qq.com
Whole thread Raw
In response to 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,

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

pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Don't overwrite scan key in systable_beginscan()
Next
From: John Naylor
Date:
Subject: Re: Linux likely() unlikely() for PostgreSQL