On Fri, Nov 27, 2020 at 6:35 PM Ajin Cherian <itsa...@gmail.com> wrote: > > On Thu, Nov 26, 2020 at 10:43 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > > I think what you need to do to reproduce this is to follow the > > snapshot machinery in SnapBuildFindSnapshot. Basically, first, start a > > transaction (say transaction-id is 500) and do some operations but > > don't commit. Here, if you create a slot (via subscription or > > otherwise), it will wait for 500 to complete and make the state as > > SNAPBUILD_BUILDING_SNAPSHOT. Here, you can commit 500 and then having > > debugger in that state, start another transaction (say 501), do some > > operations but don't commit. Next time when you reach this function, > > it will change the state to SNAPBUILD_FULL_SNAPSHOT and wait for 501, > > now you can start another transaction (say 502) which you can prepare > > but don't commit. Again start one more transaction 503, do some ops, > > commit both 501 and 503. At this stage somehow we need to ensure that > > XLOG_RUNNING_XACTS record. Then commit prepared 502. Now, I think you > > should notice that the consistent point is reached after 502's prepare > > and before its commit. Now, this is just a theoretical scenario, you > > need something on these lines and probably a way to force > > XLOG_RUNNING_XACTS WAL (probably via debugger or some other way) at > > the right times to reproduce it. > > > > Thanks for trying to build a test case for this, it is really helpful. > > I tried the above steps, I was able to get the builder state to > SNAPBUILD_BUILDING_SNAPSHOT but was not able to get into the > SNAPBUILD_FULL_SNAPSHOT state. > Instead the code moves straight from SNAPBUILD_BUILDING_SNAPSHOT to > SNAPBUILD_CONSISTENT state. >
I see the code coverage report and it appears that part of the code (get the snapshot machinery in SNAPBUILD_FULL_SNAPSHOT state) is covered by existing tests [1]. So, another idea you can try is to put a break (say while (1)) in that part of code and run regression tests (most probably the test_decoding or subscription tests should be sufficient to hit). Then once you found which existing test covers that, you can try to generate prepared transaction behavior as mentioned above. [1] - https://coverage.postgresql.org/src/backend/replication/logical/snapbuild.c.gcov.html -- With Regards, Amit Kapila.
