[Docs] Output to be Corrected in Read committed documentation

[sushantrmishra]

Description

Description

1. In https://docs.yugabyte.com/preview/architecture/transactions/read-committed/#update-behavior , The output from the final select * is wrong. Because, when update test set v=100 where v>=5; is queried in T1, 4 has value 1 (should not qualify to be considered for the update) and key 5 is non-existent at this point so that should also not be updated.
   Output should be-

k | v
----+-----
5 | 5
1 | 1
10 | 100
4 | 10
2 | 100
(5 rows)

2. In https://docs.yugabyte.com/preview/architecture/transactions/read-committed/#select-for-update-behavior ,
   The final output in T1 is wrong. k=4 should not be picked up as the condition where v>=5 at the time the select query is hit does not filter this row.
   k=5 should not be there since this row is non-existent when the select query is fired.
   The final output should be-

k | v
----+----
10 | 5
2 | 10
(2 rows)

Warning: Please confirm that this issue does not contain any sensitive information

• I confirm this issue does not contain any sensitive information.

[pkj415]

Closing this because of the same reasoning that i mentioned in #18167 -

@kripasreenivasan I earlier mentioned that this is a valid issue, but just realized this is not an issue in YSQL. This is because in YSQL's read committed isolation we are able to give a stronger guarantee than Pg -- each statement runs based off a consistent snapshot of the database. In Pg's read committed isolation, each statement can run on an inconsistent snapshot of the database.

A detailed explanation is around "Note that the preceding methodology...." in the docs page - https://docs.yugabyte.com/preview/architecture/transactions/read-committed/#update-behavior