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 will either insert or update. Unless there are unrelated errors, one of those two outcomes is guaranteed. If a conflict originates in another transaction whose effects are not yet visible to the INSERT, the UPDATE clause will affect that row, even though possibly no version of that row is conventionally visible to the command. INSERT with an ON CONFLICT DO NOTHING clause may have insertion not proceed for a row due to the outcome of another transaction whose effects are not visible to the INSERT snapshot. Again, this is only the case in Read Committed mode.' And specifically this part 'the UPDATE clause will affect that row, even though possibly no version of that row is conventionally visible to the command.' What does it mean that no version of that row is visible to the command? Is this visibility related to xmin xmax values? Or does it mean that the version of the row is not visible because it has not yet been commited by a parallel transaction? 'If a conflict originates in another transaction whose effects are not yet visible to the INSERT' - Does this mean that at the moment of starting the INSERT statement, the parallel transaction has not yet been committed (or even started after calling the INSERT statement), but at the time of performing the action with a row in the INSERT statement, transaction 2 has already committed its changes? 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? 'INSERT with the ON CONFLICT DO NOTHING clause can result in the insertion of a row not continuing due to the result of another transaction, whose effects are not visible in the instantaneous snapshot of INSERT' - same question. Could you please describe this behavior in more detail?
13.2.2. Repeatable Read Isolation Level #
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/16/transaction-iso.html Description: 'UPDATE, DELETE, MERGE, SELECT FOR UPDATE, and SELECT FOR SHARE commands behave the same as SELECT in terms of searching for target rows: they will only find target rows that were committed as of the transaction start time. However, such a target row might have already been updated (or deleted or locked) by another concurrent transaction by the time it is found. In this case, the repeatable read transaction will wait for the first updating transaction to commit or roll back (if it is still in progress). If the first updater rolls back, then its effects are negated and the repeatable read transaction can proceed with updating the originally found row. But if the first updater commits (and actually updated or deleted the row, not just locked it) then the repeatable read transaction will be rolled back with the message' What behavior does the INSERT command exhibit?
Change detail text in last example of 43.5.3. Executing a Command with a Single-Row Result
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/16/plpgsql-statements.html Description: The last example in the chapter uses a named parameter "username". As a result, the detail message should use "username" instead of "$1" to match the runtime behaviour. I suggest to change this line DETAIL: parameters: $1 = 'nosuchuser' to DETAIL: parameters: username = 'nosuchuser'
Mismatch for connection key/value pair between documentation and code?
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/16/libpq-connect.html
Description:
Hi PostgreSQL documentation team,
I have a confusion regarding parameters used in documentation vs. that in
the code. Please clarify if I misunderstand something there or.
Thanks,
Joe
For the following document regarding connect string, it is not aligned with
the code.
https://www.postgresql.org/docs/current/libpq-connect.html#LIBPQ-CONNSTRING
e.g. Timeout for connection
In the above document,it states the following:
"connect_timeout
Maximum time to wait while connecting, in seconds (write as a decimal
integer, e.g., 10). Zero, negative, or not specified means wait
indefinitely. The minimum allowed timeout is 2 seconds, therefore a value of
1 is interpreted as 2. This timeout applies separately to each host name or
IP address. For example, if you specify two hosts and connect_timeout is 5,
each host will time out if no connection is made within 5 seconds, so the
total time spent waiting for a connection might be up to 10 seconds."
However in the code:
https://github.com/npgsql/npgsql/blob/docs/src/Npgsql/NpgsqlConnectionStringBuilder.cs,
starting L789 to L812 (latest version when I raise this ticket).
The name is Timeout instead of connect_timeout, and there's no logic
regarding 2 second check
///
/// The time to wait (in seconds) while trying to establish a connection
before terminating the attempt and generating an error.
/// Defaults to 15 seconds.
///
[Category("Timeouts")]
[Description("The time to wait (in seconds) while trying to establish a
connection before terminating the attempt and generating an error.")]
[DisplayName("Timeout")]
[NpgsqlConnectionStringProperty]
[DefaultValue(DefaultTimeout)]
public int Timeout
{
get => _timeout;
set
{
if (value < 0 || value > NpgsqlConnection.TimeoutLimit)
throw new ArgumentOutOfRangeException(nameof(value), value,
"Timeout must be between 0 and " + NpgsqlConnection.TimeoutLimit);
_timeout = value;
SetValue(nameof(Timeout), value);
}
}
int _timeout;
internal const int DefaultTimeout = 15;
Re: 13.2.2. Repeatable Read Isolation Level #
On Saturday, July 13, 2024, PG Doc comments form wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/16/transaction-iso.html > Description: > > 'UPDATE, DELETE, MERGE, SELECT FOR UPDATE, and SELECT FOR SHARE commands > behave the same as SELECT in terms of searching for target rows: > > What behavior does the INSERT command exhibit? > Inserts don’t search for existing rows. David J.
Re: Mismatch for connection key/value pair between documentation and code?
On Monday, July 15, 2024, PG Doc comments form wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/16/libpq-connect.html > Description: > > > For the following document regarding connect string, it is not aligned with > the code. > https://www.postgresql.org/docs/current/libpq-connect. > html#LIBPQ-CONNSTRING > > e.g. Timeout for connection > > "connect_timeout > Maximum time to wait while connecting, in seconds (write as a decimal > integer, e.g., 10). > However in the code: > https://github.com/npgsql/npgsql/blob/docs/src/Npgsql/ > NpgsqlConnectionStringBuilder.cs, > starting L789 to L812 (latest version when I raise this ticket). > > The name is Timeout instead of connect_timeout, and there's no logic > regarding 2 second check > > Probably this third-party module is not using the libpq API. Or at minimum not that aspect of the API. David J.
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 to help you if you are that unspecific about what exactly you fail to understand. Sure, there are some complicated concepts involved. If you can't understand *anything* about that text, perhaps you should start reading the whole chapter about concurrency. Yours, Laurenz Albe
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 independent isolation mechanics. Upon attempting to insert a row that will violate the unique constraint enforced by the index the system must wait to see whether the earlier transaction commits. If it doesn't, the insert proceeds. If it does, the conflict clause is evaluated - updating the now committed row (or just doing nothing if that option is specified.) David J.
