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

From cca5507
Subject Historic snapshot doesn't track txns committed in BUILDING_SNAPSHOT state
Date
Msg-id tencent_6AAF072A7623A11A85C0B5FD290232467808@qq.com
Whole thread Raw
Responses Re: Historic snapshot doesn't track txns committed in BUILDING_SNAPSHOT state
List pgsql-hackers
Hello hackers, I found that we currently don't track txns committed in
BUILDING_SNAPSHOT state because of the code in xact_decode():
/*
* If the snapshot isn't yet fully built, we cannot decode anything, so
* bail out.
*/
if (SnapBuildCurrentState(builder) < SNAPBUILD_FULL_SNAPSHOT)
return;

This can cause a txn to take an incorrect historic snapshot and result in an
interruption of logical replication. Consider the following scenario:
(pub)create table t1 (id int primary key);
(pub)insert into t1 values (1);
(pub)create publication pub for table t1;
(sub)create table t1 (id int primary key);
(pub)begin; insert into t1 values (2); (txn1 in session1)
(sub)create subscription sub connection 'hostaddr=127.0.0.1 port=5432 user=xxx dbname=postgres' publication pub; (pub will switch to BUILDING_SNAPSHOT state soon)
(pub)begin; insert into t1 values (3); (txn2 in session2)
(pub)create table t2 (id int primary key); (session3)
(pub)commit; (commit txn1, and pub will switch to FULL_SNAPSHOT state soon)
(pub)begin; insert into t2 values (1); (txn3 in session3)
(pub)commit; (commit txn2, and pub will switch to CONSISTENT state soon)
(pub)commit; (commit txn3, and replay txn3 will failed because its snapshot cannot see table t2)

The output of pub's log:
ERROR: could not map filenumber "base/5/16395" to relation OID

Is this a bug? Should we also track the txns committed in BUILDING_SNAPSHOT state?

--
Regards,
ChangAo Chen

pgsql-hackers by date:

Previous
From: Nitin Jadhav
Date:
Subject: Re: Show WAL write and fsync stats in pg_stat_io
Next
From: Nathan Bossart
Date:
Subject: Re: problems with "Shared Memory and Semaphores" section of docs