> > Have you found a case that the v2 patch breaks? > > The v2 patch does follow the analysis in the beginning of the > discussion, which identified that in setting up parallel workers, a > "later transaction snapshot" was taken than the one actually used in > the statement execution, and that's what eventually leads to the > observed Assertion failure. > The original problem reporter stated: "So the root cause is the > Parallel Workers process set the TransactionXmin with later > transcation snapshot". > Also, as far as I can see, it makes no sense to pass parallel workers > both an active snapshot and a (later) transaction snapshot. In the > leader, prior to execution and running parallel workers, a transaction > snapshot is obtained and pushed as the active snapshot (note: only ONE > snapshot at this point). It makes little sense to me to then obtain > ANOTHER transaction snapshot when setting up parallel workers, and > pass that (only) to the workers along with the original (earlier) > active snapshot. (If there is a reason for passing the TWO snapshots > to parallel workers, original code authors and/or snapshot experts > should speak up now, and code comments should be added accordingly to > explain the purpose and how it is MEANT to work) > This is why the v2 patch updates the code to just pass one snapshot > (the active snapshot) to the parallel workers, which gets restored in > each worker as the transaction snapshot and set as the active snapshot > (so is then consistent with the snapshot setup in the parallel > leader). >
I fully agree that _probably_ two snapshots are not needed for read-only transactions. But I think we need to be very careful with everything related to transaction integrity as there are different isolation levels etc. The only fact I can not break something, seems like not an argument solid enough. Robert could you give us some help and insight into why there is a need for the separate active and transaction snapshots in the parallel infrastructure patch as per your commit 924bcf4f16d ? Until then just a workaround like v3 patch seems safer for me (still I am not a very big specialist in this). -- Best regards, Pavel Borisov Postgres Professional: http://postgrespro.com <http://www.postgrespro.com>
