pg.ddx.io pgsql-docs@postgresql.org mailing list archive
help / color / mirror / Atom feedbad choice of the word in sentence
5+ messages / 3 participants
[nested] [flat]
* bad choice of the word in sentence
@ 2023-06-22 18:38 PG Doc comments form <noreply@postgresql.org>
0 siblings, 1 reply; 5+ messages in thread
From: PG Doc comments form @ 2023-06-22 18:38 UTC (permalink / raw)
To: pgsql-docs@lists.postgresql.org; +Cc: anton.sidyakin@gmail.com
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/15/transaction-iso.html
Description:
https://www.postgresql.org/docs/current/transaction-iso.html#XACT-READ-COMMITTED
Quote:
"<...>When a transaction uses this isolation level, a SELECT query (without
a FOR UPDATE/SHARE clause) sees only data committed before the query began;
it never sees either uncommitted data or changes committed during query
execution by concurrent transactions. <...>"
"... changes committed during ..."
Don't you think this is bad choice of the word, especially while speaking
about "commiting transactions" in very same sentence?
Wouldn't it be better to say something like
<...> it never sees either uncommitted data or changes produced during query
execution by concurrent transactions. <...>
I mean, with read committed isolation level SELECT clearly can see changes
from concurrent transactions, if these transactions COMMITED.
In fact, you can read about that in few lines later:
"<...>Also note that two successive SELECT commands can see different data,
even though they are within a single transaction, if other transactions
commit changes after the first SELECT starts and before the second SELECT
starts. <...>"
The sentences seem to contradict each other because of " it never sees ...
changes committed during ..."
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: bad choice of the word in sentence
@ 2023-06-24 01:09 Bruce Momjian <bruce@momjian.us>
parent: PG Doc comments form <noreply@postgresql.org>
0 siblings, 1 reply; 5+ messages in thread
From: Bruce Momjian @ 2023-06-24 01:09 UTC (permalink / raw)
To: anton.sidyakin@gmail.com; pgsql-docs@lists.postgresql.org
On Thu, Jun 22, 2023 at 06:38:37PM +0000, PG Doc comments form wrote:
> The following documentation comment has been logged on the website:
>
> Page: https://www.postgresql.org/docs/15/transaction-iso.html
> Description:
>
> https://www.postgresql.org/docs/current/transaction-iso.html#XACT-READ-COMMITTED
>
> Quote:
> "<...>When a transaction uses this isolation level, a SELECT query (without
> a FOR UPDATE/SHARE clause) sees only data committed before the query began;
> it never sees either uncommitted data or changes committed during query
> execution by concurrent transactions. <...>"
>
> "... changes committed during ..."
>
> Don't you think this is bad choice of the word, especially while speaking
> about "commiting transactions" in very same sentence?
>
> Wouldn't it be better to say something like
> <...> it never sees either uncommitted data or changes produced during query
> execution by concurrent transactions. <...>
No, the issue is only for committed transactions, not aborted ones.
> I mean, with read committed isolation level SELECT clearly can see changes
> from concurrent transactions, if these transactions COMMITED.
No, it does not see any changes from concurrent transaction commits that
happen after the query starts, which is the point of the sentence.
> In fact, you can read about that in few lines later:
> "<...>Also note that two successive SELECT commands can see different data,
> even though they are within a single transaction, if other transactions
> commit changes after the first SELECT starts and before the second SELECT
> starts. <...>"
>
> The sentences seem to contradict each other because of " it never sees ...
> changes committed during ..."
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: bad choice of the word in sentence
@ 2023-06-24 01:16 Tom Lane <tgl@sss.pgh.pa.us>
parent: Bruce Momjian <bruce@momjian.us>
0 siblings, 1 reply; 5+ messages in thread
From: Tom Lane @ 2023-06-24 01:16 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: anton.sidyakin@gmail.com; pgsql-docs@lists.postgresql.org
Bruce Momjian <bruce@momjian.us> writes:
> On Thu, Jun 22, 2023 at 06:38:37PM +0000, PG Doc comments form wrote:
>> Quote:
>> "<...>When a transaction uses this isolation level, a SELECT query (without
>> a FOR UPDATE/SHARE clause) sees only data committed before the query began;
>> it never sees either uncommitted data or changes committed during query
>> execution by concurrent transactions. <...>"
>> Don't you think this is bad choice of the word, especially while speaking
>> about "commiting transactions" in very same sentence?
> No, the issue is only for committed transactions, not aborted ones.
I think this sentence is formally correct, but it is not very hard to
misparse. Maybe a bit of re-ordering would help? Like
... it never sees either uncommitted data or changes committed by
concurrent transactions during the query's execution.
regards, tom lane
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: bad choice of the word in sentence
@ 2023-06-24 01:20 Bruce Momjian <bruce@momjian.us>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 5+ messages in thread
From: Bruce Momjian @ 2023-06-24 01:20 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: anton.sidyakin@gmail.com; pgsql-docs@lists.postgresql.org
On Fri, Jun 23, 2023 at 09:16:39PM -0400, Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > On Thu, Jun 22, 2023 at 06:38:37PM +0000, PG Doc comments form wrote:
> >> Quote:
> >> "<...>When a transaction uses this isolation level, a SELECT query (without
> >> a FOR UPDATE/SHARE clause) sees only data committed before the query began;
> >> it never sees either uncommitted data or changes committed during query
> >> execution by concurrent transactions. <...>"
>
> >> Don't you think this is bad choice of the word, especially while speaking
> >> about "commiting transactions" in very same sentence?
>
> > No, the issue is only for committed transactions, not aborted ones.
>
> I think this sentence is formally correct, but it is not very hard to
> misparse. Maybe a bit of re-ordering would help? Like
>
> ... it never sees either uncommitted data or changes committed by
> concurrent transactions during the query's execution.
Sure.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: bad choice of the word in sentence
@ 2023-06-28 16:49 Tom Lane <tgl@sss.pgh.pa.us>
parent: Bruce Momjian <bruce@momjian.us>
0 siblings, 0 replies; 5+ messages in thread
From: Tom Lane @ 2023-06-28 16:49 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: anton.sidyakin@gmail.com; pgsql-docs@lists.postgresql.org
Bruce Momjian <bruce@momjian.us> writes:
> On Fri, Jun 23, 2023 at 09:16:39PM -0400, Tom Lane wrote:
>> I think this sentence is formally correct, but it is not very hard to
>> misparse. Maybe a bit of re-ordering would help? Like
>> ... it never sees either uncommitted data or changes committed by
>> concurrent transactions during the query's execution.
> Sure.
Done that way.
regards, tom lane
^ permalink raw reply [nested|flat] 5+ messages in thread
end of thread, other threads:[~2023-06-28 16:49 UTC | newest]
Thread overview: 5+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2023-06-22 18:38 bad choice of the word in sentence PG Doc comments form <noreply@postgresql.org>
2023-06-24 01:09 ` Bruce Momjian <bruce@momjian.us>
2023-06-24 01:16 ` Tom Lane <tgl@sss.pgh.pa.us>
2023-06-24 01:20 ` Bruce Momjian <bruce@momjian.us>
2023-06-28 16:49 ` Tom Lane <tgl@sss.pgh.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox