Re: 13.2.1. Read Committed Isolation Level

Thank you for the response. Can I clarify if I understood the essence correctly? It turns out that despite the Read Committed isolation level, due to the presence of a unique index, which has an independent isolation mechanism, a transaction can "know" that a parallel transaction has performed an i

Re: 13.2.1. Read Committed Isolation Level

On Tue, Jul 16, 2024 at 7:06 AM PG Doc comments form wrote: > Or does it mean that contrary to Read > Committed Isolation Level, uncommitted changes from a parallel transaction > can affect the execution of an INSERT command? > This. Because you are keying off of an unique index that has indepe

Re: 13.2.1. Read Committed Isolation Level

On Sun, 2024-07-14 at 06:17 +, PG Doc comments form wrote: > Page: https://www.postgresql.org/docs/16/transaction-iso.html > Description: > > I don't understend this text. > > [five paragraphs from the documentation] > > Could you please describe this behavior in more detail? It is difficult

13.2.1. Read Committed Isolation Level

The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/16/transaction-iso.html Description: I don't understend this text. 'INSERT with an ON CONFLICT DO UPDATE clause behaves similarly. In Read Committed mode, each row proposed for insertion wil

Re: Unclear\mistakable description of UPDATE behaviour in "13.2.1. Read Committed Isolation Level"

On Tue, Aug 17, 2021 at 11:18 PM radiodiversion wrote: > change sentence: "The search condition of the command (the WHERE clause) > is re-evaluated to see if the updated version of the row still matches the > search condition." > with sentence: "The search condition of the command (the WHERE clau

Re: Unclear\mistakable description of UPDATE behaviour in "13.2.1. Read Committed Isolation Level"

David, I have some suggestions. but first i want to show how the current version of doc may look like for new readers. and why. I am sure that it looks pretty logical if you KNOW how it works, but it is not so clear if you WANT to learn that from documentation. explanation: first sentence: "they

Re: Unclear\mistakable description of UPDATE behaviour in "13.2.1. Read Committed Isolation Level"

Hi, David! Thanks for the explanation! Now I clearly understand how it works. I still think it would be great if this doc point was worded a little differently in new editions. Thank you! On Wed, 18 Aug 2021 at 02:03, David G. Johnston wrote: > On Tue, Aug 17, 2021 at 3:56 PM PG Doc comments

Re: Unclear\mistakable description of UPDATE behaviour in "13.2.1. Read Committed Isolation Level"

On Tue, Aug 17, 2021 at 4:17 PM radiodiversion wrote: > I still think it would be great if this doc point was worded a little > differently in new editions. > > Suggestions are welcome. Without some idea of why you seemed to miss the two seemingly obvious references that I pointed out (including

Re: Unclear\mistakable description of UPDATE behaviour in "13.2.1. Read Committed Isolation Level"

On Tue, Aug 17, 2021 at 3:56 PM PG Doc comments form wrote: > > "UPDATE, DELETE, SELECT FOR UPDATE, and SELECT FOR SHARE commands ... > ...If the first updater commits, the second updater will ignore the row if > the first updater deleted it, otherwise it will attempt to apply its > operation to

Unclear\mistakable description of UPDATE behaviour in "13.2.1. Read Committed Isolation Level"

The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/13/transaction-iso.html Description: hello! documentation for "read committed" says that: "UPDATE, DELETE, SELECT FOR UPDATE, and SELECT FOR SHARE commands ... ...If the first updater commi