agora inbox for pgsql-docs@postgresql.org
help / color / mirror / Atom feedCorrection
20+ messages / 8 participants
[nested] [flat]
* Correction
@ 2017-11-19 19:38 demirgokhan@gmail.com
2017-11-19 21:17 ` Re: Correction Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 20+ messages in thread
From: demirgokhan@gmail.com @ 2017-11-19 19:38 UTC (permalink / raw)
To: pgsql-docs
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/9.4/static/datatype-json.html
Description:
Shouldn't be below statement:
"Although the jsonb_path_ops operator class supports only queries with the
@> operator, it has notable performance advantages over the default operator
class jsonb_ops."
corrected to:
"Although the jsonb_path_ops operator class supports only queries with the ?
operator, it has notable performance advantages over the default operator
class jsonb_ops."
on the page https://www.postgresql.org/docs/9.4/static/datatype-json.html
--
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs
^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: Correction
2017-11-19 19:38 Correction demirgokhan@gmail.com
@ 2017-11-19 21:17 ` Tom Lane <tgl@sss.pgh.pa.us>
2017-11-21 19:11 ` Re: [DOCS] Correction Gokhan Demir <demirgokhan@gmail.com>
0 siblings, 1 reply; 20+ messages in thread
From: Tom Lane @ 2017-11-19 21:17 UTC (permalink / raw)
To: demirgokhan@gmail.com; +Cc: pgsql-docs
demirgokhan@gmail.com writes:
> The following documentation comment has been logged on the website:
> Page: https://www.postgresql.org/docs/9.4/static/datatype-json.html
> Description:
> Shouldn't be below statement:
> "Although the jsonb_path_ops operator class supports only queries with the
> @> operator, it has notable performance advantages over the default operator
> class jsonb_ops."
> corrected to:
> "Although the jsonb_path_ops operator class supports only queries with the ?
> operator, it has notable performance advantages over the default operator
> class jsonb_ops."
Uh, no, I don't think so:
regression=# select oid from pg_opfamily where opfname = 'jsonb_path_ops';
oid
------
4037
(1 row)
regression=# select amopopr::regoperator from pg_amop where amopfamily = 4037;
amopopr
-----------------
@>(jsonb,jsonb)
(1 row)
regards, tom lane
--
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs
^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: [DOCS] Correction
2017-11-19 19:38 Correction demirgokhan@gmail.com
2017-11-19 21:17 ` Re: Correction Tom Lane <tgl@sss.pgh.pa.us>
@ 2017-11-21 19:11 ` Gokhan Demir <demirgokhan@gmail.com>
0 siblings, 0 replies; 20+ messages in thread
From: Gokhan Demir @ 2017-11-21 19:11 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-docs
Hi Tom,
Then I guess I will need to read that part of the chapter again.
Many thanks for the clarification.
Gokhan.
On Mon, Nov 20, 2017 at 12:17 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> demirgokhan@gmail.com writes:
> > The following documentation comment has been logged on the website:
> > Page: https://www.postgresql.org/docs/9.4/static/datatype-json.html
> > Description:
>
> > Shouldn't be below statement:
>
> > "Although the jsonb_path_ops operator class supports only queries
> with the
> > @> operator, it has notable performance advantages over the default
> operator
> > class jsonb_ops."
>
> > corrected to:
>
> > "Although the jsonb_path_ops operator class supports only queries
> with the ?
> > operator, it has notable performance advantages over the default operator
> > class jsonb_ops."
>
> Uh, no, I don't think so:
>
> regression=# select oid from pg_opfamily where opfname = 'jsonb_path_ops';
> oid
> ------
> 4037
> (1 row)
>
> regression=# select amopopr::regoperator from pg_amop where amopfamily =
> 4037;
> amopopr
> -----------------
> @>(jsonb,jsonb)
> (1 row)
>
> regards, tom lane
>
^ permalink raw reply [nested|flat] 20+ messages in thread
* correction
@ 2022-05-11 00:33 PG Doc comments form <noreply@postgresql.org>
2022-05-11 10:36 ` Re: correction Laurenz Albe <laurenz.albe@cybertec.at>
0 siblings, 1 reply; 20+ messages in thread
From: PG Doc comments form @ 2022-05-11 00:33 UTC (permalink / raw)
To: pgsql-docs@lists.postgresql.org; +Cc: akhilhello@gmail.com
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/14/transaction-iso.html
Description:
in this page: https://www.postgresql.org/docs/14/transaction-iso.html
under the Table 13.1 section, if we search for "phantom reads. Stricter
behavior is permitted by the SQL standard", do we mean "Looser behaviour"?
^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: correction
2022-05-11 00:33 correction PG Doc comments form <noreply@postgresql.org>
@ 2022-05-11 10:36 ` Laurenz Albe <laurenz.albe@cybertec.at>
2022-05-13 20:36 ` Re: correction Bruce Momjian <bruce@momjian.us>
0 siblings, 1 reply; 20+ messages in thread
From: Laurenz Albe @ 2022-05-11 10:36 UTC (permalink / raw)
To: akhilhello@gmail.com; pgsql-docs@lists.postgresql.org
On Wed, 2022-05-11 at 00:33 +0000, PG Doc comments form wrote:
> The following documentation comment has been logged on the website:
>
> Page: https://www.postgresql.org/docs/14/transaction-iso.html
> Description:
>
> in this page: https://www.postgresql.org/docs/14/transaction-iso.html
>
> under the Table 13.1 section, if we search for "phantom reads. Stricter
> behavior is permitted by the SQL standard", do we mean "Looser behaviour"?
What is meant is "The SQL standard allows an implementation to implement
stricter behavior than required by the standard; it only defines the things
that are *not* allowed to happen at a certain isolation level. So it is for
example fine for PostgreSQL not to allow dirty reads in READ UNCOMMITTED
isolation level."
Perhaps this could be rewritten to be clearer; it is indeed easy to
misunderstand that sentence.
Yours,
Laurenz Albe
^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: correction
2022-05-11 00:33 correction PG Doc comments form <noreply@postgresql.org>
2022-05-11 10:36 ` Re: correction Laurenz Albe <laurenz.albe@cybertec.at>
@ 2022-05-13 20:36 ` Bruce Momjian <bruce@momjian.us>
2022-05-13 21:49 ` Re: correction Laurenz Albe <laurenz.albe@cybertec.at>
0 siblings, 1 reply; 20+ messages in thread
From: Bruce Momjian @ 2022-05-13 20:36 UTC (permalink / raw)
To: Laurenz Albe <laurenz.albe@cybertec.at>; +Cc: akhilhello@gmail.com; pgsql-docs@lists.postgresql.org
On Wed, May 11, 2022 at 12:36:11PM +0200, Laurenz Albe wrote:
> On Wed, 2022-05-11 at 00:33 +0000, PG Doc comments form wrote:
> > The following documentation comment has been logged on the website:
> >
> > Page: https://www.postgresql.org/docs/14/transaction-iso.html
> > Description:
> >
> > in this page: https://www.postgresql.org/docs/14/transaction-iso.html
> >
> > under the Table 13.1 section, if we search for "phantom reads. Stricter
> > behavior is permitted by the SQL standard", do we mean "Looser behaviour"?
>
> What is meant is "The SQL standard allows an implementation to implement
> stricter behavior than required by the standard; it only defines the things
> that are *not* allowed to happen at a certain isolation level. So it is for
> example fine for PostgreSQL not to allow dirty reads in READ UNCOMMITTED
> isolation level."
>
> Perhaps this could be rewritten to be clearer; it is indeed easy to
> misunderstand that sentence.
How is this attached patch's wording?
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com
Indecision is a decision. Inaction is an action. Mark Batterson
Attachments:
[text/x-diff] strict.diff (731B, ../../Yn7BMql7NFkQLAdc@momjian.us/2-strict.diff)
download | inline diff:
diff --git a/doc/src/sgml/mvcc.sgml b/doc/src/sgml/mvcc.sgml
index 341fea524a..244694b07f 100644
--- a/doc/src/sgml/mvcc.sgml
+++ b/doc/src/sgml/mvcc.sgml
@@ -277,8 +277,8 @@
<para>
The table also shows that PostgreSQL's Repeatable Read implementation
- does not allow phantom reads. Stricter behavior is permitted by the
- SQL standard: the four isolation levels only define which phenomena
+ does not allow phantom reads. The SQL standard allows more restrictive
+ behavior: the four isolation levels only define which phenomena
must not happen, not which phenomena <emphasis>must</emphasis> happen.
The behavior of the available isolation levels is detailed in the
following subsections.
^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: correction
2022-05-11 00:33 correction PG Doc comments form <noreply@postgresql.org>
2022-05-11 10:36 ` Re: correction Laurenz Albe <laurenz.albe@cybertec.at>
2022-05-13 20:36 ` Re: correction Bruce Momjian <bruce@momjian.us>
@ 2022-05-13 21:49 ` Laurenz Albe <laurenz.albe@cybertec.at>
2022-05-13 22:16 ` Re: correction David G. Johnston <david.g.johnston@gmail.com>
2022-06-07 21:07 ` Re: correction Bruce Momjian <bruce@momjian.us>
0 siblings, 2 replies; 20+ messages in thread
From: Laurenz Albe @ 2022-05-13 21:49 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: akhilhello@gmail.com; pgsql-docs@lists.postgresql.org
On Fri, 2022-05-13 at 16:36 -0400, Bruce Momjian wrote:
> On Wed, May 11, 2022 at 12:36:11PM +0200, Laurenz Albe wrote:
> > On Wed, 2022-05-11 at 00:33 +0000, PG Doc comments form wrote:
> > > The following documentation comment has been logged on the website:
> > >
> > > Page: https://www.postgresql.org/docs/14/transaction-iso.html
> > > Description:
> > >
> > > in this page: https://www.postgresql.org/docs/14/transaction-iso.html
> > >
> > > under the Table 13.1 section, if we search for "phantom reads. Stricter
> > > behavior is permitted by the SQL standard", do we mean "Looser behaviour"?
> >
> > What is meant is "The SQL standard allows an implementation to implement
> > stricter behavior than required by the standard; it only defines the things
> > that are *not* allowed to happen at a certain isolation level. So it is for
> > example fine for PostgreSQL not to allow dirty reads in READ UNCOMMITTED
> > isolation level."
> >
> > Perhaps this could be rewritten to be clearer; it is indeed easy to
> > misunderstand that sentence.
>
> How is this attached patch's wording?
>
> diff --git a/doc/src/sgml/mvcc.sgml b/doc/src/sgml/mvcc.sgml
> index 341fea524a..244694b07f 100644
> --- a/doc/src/sgml/mvcc.sgml
> +++ b/doc/src/sgml/mvcc.sgml
> @@ -277,8 +277,8 @@
>
> <para>
> The table also shows that PostgreSQL's Repeatable Read implementation
> - does not allow phantom reads. Stricter behavior is permitted by the
> - SQL standard: the four isolation levels only define which phenomena
> + does not allow phantom reads. The SQL standard allows more restrictive
> + behavior: the four isolation levels only define which phenomena
> must not happen, not which phenomena <emphasis>must</emphasis> happen.
> The behavior of the available isolation levels is detailed in the
> following subsections.
I think that suffers from the same problem: izt sounds like the standard allows
stricter behavior than PostgreSQL.
How about:
The table also shows that PostgreSQL's Repeatable Read implementation
does not allow phantom reads. That is fine, because the SQL standard only
specifies which anomalies must <emphasis>not</enphasis> occur at a certain
isolation level. It is no problem if an implementation provides higher
guarantees than required.
The behavior of the available isolation levels is detailed in the
following subsections.
Yours,
Laurenz Albe
^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: correction
2022-05-11 00:33 correction PG Doc comments form <noreply@postgresql.org>
2022-05-11 10:36 ` Re: correction Laurenz Albe <laurenz.albe@cybertec.at>
2022-05-13 20:36 ` Re: correction Bruce Momjian <bruce@momjian.us>
2022-05-13 21:49 ` Re: correction Laurenz Albe <laurenz.albe@cybertec.at>
@ 2022-05-13 22:16 ` David G. Johnston <david.g.johnston@gmail.com>
1 sibling, 0 replies; 20+ messages in thread
From: David G. Johnston @ 2022-05-13 22:16 UTC (permalink / raw)
To: Laurenz Albe <laurenz.albe@cybertec.at>; +Cc: Bruce Momjian <bruce@momjian.us>; akhilhello@gmail.com, Pg Docs <pgsql-docs@lists.postgresql.org>
On Fri, May 13, 2022 at 2:49 PM Laurenz Albe <laurenz.albe@cybertec.at>
wrote:
> On Fri, 2022-05-13 at 16:36 -0400, Bruce Momjian wrote:
> > On Wed, May 11, 2022 at 12:36:11PM +0200, Laurenz Albe wrote:
> > > On Wed, 2022-05-11 at 00:33 +0000, PG Doc comments form wrote:
> > > > The following documentation comment has been logged on the website:
> > > >
> > > > Page: https://www.postgresql.org/docs/14/transaction-iso.html
> > > > Description:
> > > >
> > > > in this page:
> https://www.postgresql.org/docs/14/transaction-iso.html
> > > >
> > > > under the Table 13.1 section, if we search for "phantom reads.
> Stricter
> > > > behavior is permitted by the SQL standard", do we mean "Looser
> behaviour"?
> > >
> > > What is meant is "The SQL standard allows an implementation to
> implement
> > > stricter behavior than required by the standard; it only defines the
> things
> > > that are *not* allowed to happen at a certain isolation level. So it
> is for
> > > example fine for PostgreSQL not to allow dirty reads in READ
> UNCOMMITTED
> > > isolation level."
> > >
> > > Perhaps this could be rewritten to be clearer; it is indeed easy to
> > > misunderstand that sentence.
> >
> > How is this attached patch's wording?
> >
> > diff --git a/doc/src/sgml/mvcc.sgml b/doc/src/sgml/mvcc.sgml
> > index 341fea524a..244694b07f 100644
> > --- a/doc/src/sgml/mvcc.sgml
> > +++ b/doc/src/sgml/mvcc.sgml
> > @@ -277,8 +277,8 @@
> >
> > <para>
> > The table also shows that PostgreSQL's Repeatable Read
> implementation
> > - does not allow phantom reads. Stricter behavior is permitted by the
> > - SQL standard: the four isolation levels only define which phenomena
> > + does not allow phantom reads. The SQL standard allows more
> restrictive
> > + behavior: the four isolation levels only define which phenomena
> > must not happen, not which phenomena <emphasis>must</emphasis>
> happen.
> > The behavior of the available isolation levels is detailed in the
> > following subsections.
>
> I think that suffers from the same problem: izt sounds like the standard
> allows
> stricter behavior than PostgreSQL.
>
> How about:
>
> The table also shows that PostgreSQL's Repeatable Read implementation
> does not allow phantom reads. That is fine, because the SQL standard
> only
> specifies which anomalies must <emphasis>not</enphasis> occur at a
> certain
> isolation level. It is no problem if an implementation provides higher
> guarantees than required.
> The behavior of the available isolation levels is detailed in the
> following subsections.
>
>
>
How about this?
I really dislike the table having "Allow, but" - it's not allowed and
having the reader have to interpret "but" to understand the "not possible"
aspect of the cell seems unnecessary. The "in PG" qualification and a note
makes it perfectly clear where we deviate from the standard - on the binary
option.
I also suggest (but did not implement) taking out the mention of the RR
exception from here and just leaving the main section where we repeat for a
second time what is self-evident from reading the table (so, three mentions
of this implementation choice):
"This is a stronger guarantee than is required by the SQL standard for this
isolation level, and prevents all of the phenomena described in Table 13.1
except for serialization anomalies. As mentioned above, this is
specifically allowed by the standard, which only describes the minimum
protections each isolation level must provide."
David J.
<entry>
- Allowed, but not in PG
+ Not possible in PG
</entry>
<entry>
Possible
@@ -238,7 +238,7 @@
Not possible
</entry>
<entry>
- Allowed, but not in PG
+ Not possible in PG
</entry>
<entry>
Possible
@@ -266,6 +266,12 @@
</tgroup>
</table>
+ <para>
+ Two entries in the above table are qualified by "in PG". For these,
+ the SQL standard deems the corresponding anomaly possible at that
+ isolation level but permits implementations to make it impossible.
+ </para>
Attachments:
[application/octet-stream] doc-mvcc-transaction-iso.diff (1.5K, ../../CAKFQuwYGM1-VgMQQLH3xPO-tsOYkMH=n1Q_O46yo97caRxcmKg@mail.gmail.com/3-doc-mvcc-transaction-iso.diff)
download | inline diff:
diff --git a/doc/src/sgml/mvcc.sgml b/doc/src/sgml/mvcc.sgml
index 341fea524a..137f0ab204 100644
--- a/doc/src/sgml/mvcc.sgml
+++ b/doc/src/sgml/mvcc.sgml
@@ -196,7 +196,7 @@
Read uncommitted
</entry>
<entry>
- Allowed, but not in PG
+ Not possible in PG
</entry>
<entry>
Possible
@@ -238,7 +238,7 @@
Not possible
</entry>
<entry>
- Allowed, but not in PG
+ Not possible in PG
</entry>
<entry>
Possible
@@ -266,6 +266,12 @@
</tgroup>
</table>
+ <para>
+ Two entries in the above table are qualified by "in PG". For these,
+ the SQL standard deems the corresponding anomaly possible at that
+ isolation level but permits implementations to make it impossible.
+ </para>
+
<para>
In <productname>PostgreSQL</productname>, you can request any of
the four standard transaction isolation levels, but internally only
@@ -277,9 +283,10 @@
<para>
The table also shows that PostgreSQL's Repeatable Read implementation
- does not allow phantom reads. Stricter behavior is permitted by the
- SQL standard: the four isolation levels only define which phenomena
- must not happen, not which phenomena <emphasis>must</emphasis> happen.
+ does not allow SQL stardard permissible phantom reads.
+ </para>
+
+ <para>
The behavior of the available isolation levels is detailed in the
following subsections.
</para>
^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: correction
2022-05-11 00:33 correction PG Doc comments form <noreply@postgresql.org>
2022-05-11 10:36 ` Re: correction Laurenz Albe <laurenz.albe@cybertec.at>
2022-05-13 20:36 ` Re: correction Bruce Momjian <bruce@momjian.us>
2022-05-13 21:49 ` Re: correction Laurenz Albe <laurenz.albe@cybertec.at>
@ 2022-06-07 21:07 ` Bruce Momjian <bruce@momjian.us>
2022-06-07 21:40 ` Re: correction David G. Johnston <david.g.johnston@gmail.com>
1 sibling, 1 reply; 20+ messages in thread
From: Bruce Momjian @ 2022-06-07 21:07 UTC (permalink / raw)
To: Laurenz Albe <laurenz.albe@cybertec.at>; +Cc: akhilhello@gmail.com; pgsql-docs@lists.postgresql.org
On Fri, May 13, 2022 at 11:49:09PM +0200, Laurenz Albe wrote:
> I think that suffers from the same problem: izt sounds like the standard allows
> stricter behavior than PostgreSQL.
>
> How about:
>
> The table also shows that PostgreSQL's Repeatable Read implementation
> does not allow phantom reads. That is fine, because the SQL standard only
> specifies which anomalies must <emphasis>not</enphasis> occur at a certain
> isolation level. It is no problem if an implementation provides higher
> guarantees than required.
> The behavior of the available isolation levels is detailed in the
> following subsections.
How is this, attached?
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com
Indecision is a decision. Inaction is an action. Mark Batterson
Attachments:
[text/x-diff] strict.diff (837B, ../../Yp++HQ6s6xomcCx8@momjian.us/2-strict.diff)
download | inline diff:
diff --git a/doc/src/sgml/mvcc.sgml b/doc/src/sgml/mvcc.sgml
index 341fea524a..112d6ce7a8 100644
--- a/doc/src/sgml/mvcc.sgml
+++ b/doc/src/sgml/mvcc.sgml
@@ -277,9 +277,10 @@
<para>
The table also shows that PostgreSQL's Repeatable Read implementation
- does not allow phantom reads. Stricter behavior is permitted by the
- SQL standard: the four isolation levels only define which phenomena
- must not happen, not which phenomena <emphasis>must</emphasis> happen.
+ does not allow phantom reads. This is acceptable under the SQL
+ standard because the standard specifies which anomalies must
+ <emphasis>not</enphasis> occur at certain isolation levels; higher
+ guarantees are acceptable.
The behavior of the available isolation levels is detailed in the
following subsections.
</para>
^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: correction
2022-05-11 00:33 correction PG Doc comments form <noreply@postgresql.org>
2022-05-11 10:36 ` Re: correction Laurenz Albe <laurenz.albe@cybertec.at>
2022-05-13 20:36 ` Re: correction Bruce Momjian <bruce@momjian.us>
2022-05-13 21:49 ` Re: correction Laurenz Albe <laurenz.albe@cybertec.at>
2022-06-07 21:07 ` Re: correction Bruce Momjian <bruce@momjian.us>
@ 2022-06-07 21:40 ` David G. Johnston <david.g.johnston@gmail.com>
2022-06-07 23:51 ` Re: correction Bruce Momjian <bruce@momjian.us>
0 siblings, 1 reply; 20+ messages in thread
From: David G. Johnston @ 2022-06-07 21:40 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: Laurenz Albe <laurenz.albe@cybertec.at>; akhilhello@gmail.com, Pg Docs <pgsql-docs@lists.postgresql.org>
On Tue, Jun 7, 2022 at 2:07 PM Bruce Momjian <bruce@momjian.us> wrote:
>
>
> How is this, attached?
>
>
Works for me.
Capital "S" in Standard as a proper name? (mind grepping this to see how
consistent we are one way or the other, I'm not setup for that at the
moment)
David J.
^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: correction
2022-05-11 00:33 correction PG Doc comments form <noreply@postgresql.org>
2022-05-11 10:36 ` Re: correction Laurenz Albe <laurenz.albe@cybertec.at>
2022-05-13 20:36 ` Re: correction Bruce Momjian <bruce@momjian.us>
2022-05-13 21:49 ` Re: correction Laurenz Albe <laurenz.albe@cybertec.at>
2022-06-07 21:07 ` Re: correction Bruce Momjian <bruce@momjian.us>
2022-06-07 21:40 ` Re: correction David G. Johnston <david.g.johnston@gmail.com>
@ 2022-06-07 23:51 ` Bruce Momjian <bruce@momjian.us>
2022-06-07 23:53 ` Re: correction David G. Johnston <david.g.johnston@gmail.com>
2022-06-08 00:00 ` Re: correction Tom Lane <tgl@sss.pgh.pa.us>
2022-06-22 18:33 ` Re: correction Bruce Momjian <bruce@momjian.us>
0 siblings, 3 replies; 20+ messages in thread
From: Bruce Momjian @ 2022-06-07 23:51 UTC (permalink / raw)
To: David G. Johnston <david.g.johnston@gmail.com>; +Cc: Laurenz Albe <laurenz.albe@cybertec.at>; akhilhello@gmail.com, Pg Docs <pgsql-docs@lists.postgresql.org>
On Tue, Jun 7, 2022 at 02:40:41PM -0700, David G. Johnston wrote:
> On Tue, Jun 7, 2022 at 2:07 PM Bruce Momjian <bruce@momjian.us> wrote:
>
>
>
> How is this, attached?
>
>
>
> Works for me.
>
> Capital "S" in Standard as a proper name? (mind grepping this to see how
> consistent we are one way or the other, I'm not setup for that at the moment)
Well, that's a good question. Seems we use "SQL standard", and I found
one place where we capitalize "Standard", so fixed too in this patch.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com
Indecision is a decision. Inaction is an action. Mark Batterson
Attachments:
[text/x-diff] strict.diff (1.5K, ../../Yp%2FkeGF4wzuvULNO@momjian.us/2-strict.diff)
download | inline diff:
diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml
index c7e402765f..3df4cda716 100644
--- a/doc/src/sgml/high-availability.sgml
+++ b/doc/src/sgml/high-availability.sgml
@@ -2194,7 +2194,7 @@ HINT: You can then restart the server after making the necessary configuration
Currently, temporary table creation is not allowed during read-only
transactions, so in some cases existing scripts will not run correctly.
This restriction might be relaxed in a later release. This is
- both an SQL Standard compliance issue and a technical issue.
+ both an SQL standard compliance issue and a technical issue.
</para>
<para>
diff --git a/doc/src/sgml/mvcc.sgml b/doc/src/sgml/mvcc.sgml
index 341fea524a..112d6ce7a8 100644
--- a/doc/src/sgml/mvcc.sgml
+++ b/doc/src/sgml/mvcc.sgml
@@ -277,9 +277,10 @@
<para>
The table also shows that PostgreSQL's Repeatable Read implementation
- does not allow phantom reads. Stricter behavior is permitted by the
- SQL standard: the four isolation levels only define which phenomena
- must not happen, not which phenomena <emphasis>must</emphasis> happen.
+ does not allow phantom reads. This is acceptable under the SQL
+ standard because the standard specifies which anomalies must
+ <emphasis>not</enphasis> occur at certain isolation levels; higher
+ guarantees are acceptable.
The behavior of the available isolation levels is detailed in the
following subsections.
</para>
^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: correction
2022-05-11 00:33 correction PG Doc comments form <noreply@postgresql.org>
2022-05-11 10:36 ` Re: correction Laurenz Albe <laurenz.albe@cybertec.at>
2022-05-13 20:36 ` Re: correction Bruce Momjian <bruce@momjian.us>
2022-05-13 21:49 ` Re: correction Laurenz Albe <laurenz.albe@cybertec.at>
2022-06-07 21:07 ` Re: correction Bruce Momjian <bruce@momjian.us>
2022-06-07 21:40 ` Re: correction David G. Johnston <david.g.johnston@gmail.com>
2022-06-07 23:51 ` Re: correction Bruce Momjian <bruce@momjian.us>
@ 2022-06-07 23:53 ` David G. Johnston <david.g.johnston@gmail.com>
2 siblings, 0 replies; 20+ messages in thread
From: David G. Johnston @ 2022-06-07 23:53 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: Laurenz Albe <laurenz.albe@cybertec.at>; akhilhello@gmail.com, Pg Docs <pgsql-docs@lists.postgresql.org>
On Tue, Jun 7, 2022 at 4:51 PM Bruce Momjian <bruce@momjian.us> wrote:
> On Tue, Jun 7, 2022 at 02:40:41PM -0700, David G. Johnston wrote:
> > On Tue, Jun 7, 2022 at 2:07 PM Bruce Momjian <bruce@momjian.us> wrote:
> >
> >
> >
> > How is this, attached?
> >
> >
> >
> > Works for me.
> >
> > Capital "S" in Standard as a proper name? (mind grepping this to see how
> > consistent we are one way or the other, I'm not setup for that at the
> moment)
>
> Well, that's a good question. Seems we use "SQL standard", and I found
> one place where we capitalize "Standard", so fixed too in this patch.
>
+1
Thanks!
David J.
^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: correction
2022-05-11 00:33 correction PG Doc comments form <noreply@postgresql.org>
2022-05-11 10:36 ` Re: correction Laurenz Albe <laurenz.albe@cybertec.at>
2022-05-13 20:36 ` Re: correction Bruce Momjian <bruce@momjian.us>
2022-05-13 21:49 ` Re: correction Laurenz Albe <laurenz.albe@cybertec.at>
2022-06-07 21:07 ` Re: correction Bruce Momjian <bruce@momjian.us>
2022-06-07 21:40 ` Re: correction David G. Johnston <david.g.johnston@gmail.com>
2022-06-07 23:51 ` Re: correction Bruce Momjian <bruce@momjian.us>
@ 2022-06-08 00:00 ` Tom Lane <tgl@sss.pgh.pa.us>
2022-06-08 00:26 ` Re: correction Bruce Momjian <bruce@momjian.us>
2 siblings, 1 reply; 20+ messages in thread
From: Tom Lane @ 2022-06-08 00:00 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: David G. Johnston <david.g.johnston@gmail.com>; Laurenz Albe <laurenz.albe@cybertec.at>; akhilhello@gmail.com, Pg Docs <pgsql-docs@lists.postgresql.org>
Bruce Momjian <bruce@momjian.us> writes:
> + <emphasis>not</enphasis> occur at certain isolation levels; higher
The docs toolchain is not gonna like that.
regards, tom lane
^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: correction
2022-05-11 00:33 correction PG Doc comments form <noreply@postgresql.org>
2022-05-11 10:36 ` Re: correction Laurenz Albe <laurenz.albe@cybertec.at>
2022-05-13 20:36 ` Re: correction Bruce Momjian <bruce@momjian.us>
2022-05-13 21:49 ` Re: correction Laurenz Albe <laurenz.albe@cybertec.at>
2022-06-07 21:07 ` Re: correction Bruce Momjian <bruce@momjian.us>
2022-06-07 21:40 ` Re: correction David G. Johnston <david.g.johnston@gmail.com>
2022-06-07 23:51 ` Re: correction Bruce Momjian <bruce@momjian.us>
2022-06-08 00:00 ` Re: correction Tom Lane <tgl@sss.pgh.pa.us>
@ 2022-06-08 00:26 ` Bruce Momjian <bruce@momjian.us>
2022-06-09 23:18 ` Re: correction David G. Johnston <david.g.johnston@gmail.com>
0 siblings, 1 reply; 20+ messages in thread
From: Bruce Momjian @ 2022-06-08 00:26 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: David G. Johnston <david.g.johnston@gmail.com>; Laurenz Albe <laurenz.albe@cybertec.at>; akhilhello@gmail.com, Pg Docs <pgsql-docs@lists.postgresql.org>
On Tue, Jun 7, 2022 at 08:00:16PM -0400, Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > + <emphasis>not</enphasis> occur at certain isolation levels; higher
>
> The docs toolchain is not gonna like that.
You are correct. I should have tested, updated patch attached.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com
Indecision is a decision. Inaction is an action. Mark Batterson
Attachments:
[text/x-diff] strict.diff (1.5K, ../../Yp%2Fssfs+kBV6krjR@momjian.us/2-strict.diff)
download | inline diff:
diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml
index c7e402765f..3df4cda716 100644
--- a/doc/src/sgml/high-availability.sgml
+++ b/doc/src/sgml/high-availability.sgml
@@ -2194,7 +2194,7 @@ HINT: You can then restart the server after making the necessary configuration
Currently, temporary table creation is not allowed during read-only
transactions, so in some cases existing scripts will not run correctly.
This restriction might be relaxed in a later release. This is
- both an SQL Standard compliance issue and a technical issue.
+ both an SQL standard compliance issue and a technical issue.
</para>
<para>
diff --git a/doc/src/sgml/mvcc.sgml b/doc/src/sgml/mvcc.sgml
index 341fea524a..c9c4f943c9 100644
--- a/doc/src/sgml/mvcc.sgml
+++ b/doc/src/sgml/mvcc.sgml
@@ -277,9 +277,10 @@
<para>
The table also shows that PostgreSQL's Repeatable Read implementation
- does not allow phantom reads. Stricter behavior is permitted by the
- SQL standard: the four isolation levels only define which phenomena
- must not happen, not which phenomena <emphasis>must</emphasis> happen.
+ does not allow phantom reads. This is acceptable under the SQL
+ standard because the standard specifies which anomalies must
+ <emphasis>not</emphasis> occur at certain isolation levels; higher
+ guarantees are acceptable.
The behavior of the available isolation levels is detailed in the
following subsections.
</para>
^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: correction
2022-05-11 00:33 correction PG Doc comments form <noreply@postgresql.org>
2022-05-11 10:36 ` Re: correction Laurenz Albe <laurenz.albe@cybertec.at>
2022-05-13 20:36 ` Re: correction Bruce Momjian <bruce@momjian.us>
2022-05-13 21:49 ` Re: correction Laurenz Albe <laurenz.albe@cybertec.at>
2022-06-07 21:07 ` Re: correction Bruce Momjian <bruce@momjian.us>
2022-06-07 21:40 ` Re: correction David G. Johnston <david.g.johnston@gmail.com>
2022-06-07 23:51 ` Re: correction Bruce Momjian <bruce@momjian.us>
2022-06-08 00:00 ` Re: correction Tom Lane <tgl@sss.pgh.pa.us>
2022-06-08 00:26 ` Re: correction Bruce Momjian <bruce@momjian.us>
@ 2022-06-09 23:18 ` David G. Johnston <david.g.johnston@gmail.com>
0 siblings, 0 replies; 20+ messages in thread
From: David G. Johnston @ 2022-06-09 23:18 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Laurenz Albe <laurenz.albe@cybertec.at>; akhilhello@gmail.com, Pg Docs <pgsql-docs@lists.postgresql.org>
On Tue, Jun 7, 2022 at 5:26 PM Bruce Momjian <bruce@momjian.us> wrote:
> On Tue, Jun 7, 2022 at 08:00:16PM -0400, Tom Lane wrote:
> > Bruce Momjian <bruce@momjian.us> writes:
> > > + <emphasis>not</enphasis> occur at certain isolation levels;
> higher
> >
> > The docs toolchain is not gonna like that.
>
> You are correct. I should have tested, updated patch attached.
>
>
I can confirm the build and am still good with the content.
David J.
^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: correction
2022-05-11 00:33 correction PG Doc comments form <noreply@postgresql.org>
2022-05-11 10:36 ` Re: correction Laurenz Albe <laurenz.albe@cybertec.at>
2022-05-13 20:36 ` Re: correction Bruce Momjian <bruce@momjian.us>
2022-05-13 21:49 ` Re: correction Laurenz Albe <laurenz.albe@cybertec.at>
2022-06-07 21:07 ` Re: correction Bruce Momjian <bruce@momjian.us>
2022-06-07 21:40 ` Re: correction David G. Johnston <david.g.johnston@gmail.com>
2022-06-07 23:51 ` Re: correction Bruce Momjian <bruce@momjian.us>
@ 2022-06-22 18:33 ` Bruce Momjian <bruce@momjian.us>
2 siblings, 0 replies; 20+ messages in thread
From: Bruce Momjian @ 2022-06-22 18:33 UTC (permalink / raw)
To: David G. Johnston <david.g.johnston@gmail.com>; +Cc: Laurenz Albe <laurenz.albe@cybertec.at>; akhilhello@gmail.com, Pg Docs <pgsql-docs@lists.postgresql.org>
On Tue, Jun 7, 2022 at 07:51:20PM -0400, Bruce Momjian wrote:
> On Tue, Jun 7, 2022 at 02:40:41PM -0700, David G. Johnston wrote:
> > On Tue, Jun 7, 2022 at 2:07 PM Bruce Momjian <bruce@momjian.us> wrote:
> >
> >
> >
> > How is this, attached?
> >
> >
> >
> > Works for me.
> >
> > Capital "S" in Standard as a proper name? (mind grepping this to see how
> > consistent we are one way or the other, I'm not setup for that at the moment)
>
> Well, that's a good question. Seems we use "SQL standard", and I found
> one place where we capitalize "Standard", so fixed too in this patch.
Applied to all supported branches.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com
Indecision is a decision. Inaction is an action. Mark Batterson
^ permalink raw reply [nested|flat] 20+ messages in thread
* Correction
@ 2022-07-22 00:24 PG Doc comments form <noreply@postgresql.org>
2022-07-24 19:39 ` Re: Correction Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 20+ messages in thread
From: PG Doc comments form @ 2022-07-22 00:24 UTC (permalink / raw)
To: pgsql-docs@lists.postgresql.org; +Cc: chu_z@hotmail.com
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/14/citext.html
Description:
"If you declare a column as UNIQUE or PRIMARY KEY, the implicitly generated
index is case-sensitive. So it's useless for case-insensitive searches, and
it won't enforce uniqueness case-insensitively."
I think the statement above is not correct. I tried creating a PK or unique
key index on a CITEXT column. It checks uniqueness in case-insensitivity.
Here is the error I got when I tried to add a duplicated value 'Des'.
DETAIL: Key (des)=(Des) already exists.
^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: Correction
2022-07-22 00:24 Correction PG Doc comments form <noreply@postgresql.org>
@ 2022-07-24 19:39 ` Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 20+ messages in thread
From: Tom Lane @ 2022-07-24 19:39 UTC (permalink / raw)
To: chu_z@hotmail.com; +Cc: pgsql-docs@lists.postgresql.org
PG Doc comments form <noreply@postgresql.org> writes:
> "If you declare a column as UNIQUE or PRIMARY KEY, the implicitly generated
> index is case-sensitive. So it's useless for case-insensitive searches, and
> it won't enforce uniqueness case-insensitively."
> I think the statement above is not correct. I tried creating a PK or unique
> key index on a CITEXT column. It checks uniqueness in case-insensitivity.
That paragraph is talking about what happens when you *don't* use citext.
regards, tom lane
^ permalink raw reply [nested|flat] 20+ messages in thread
* correction
@ 2025-02-24 06:52 PG Doc comments form <noreply@postgresql.org>
2025-02-27 22:57 ` Re: correction Euler Taveira <euler@eulerto.com>
0 siblings, 1 reply; 20+ messages in thread
From: PG Doc comments form @ 2025-02-24 06:52 UTC (permalink / raw)
To: pgsql-docs@lists.postgresql.org; +Cc: izumi.kuramura@gmail.com
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/17/routine-vacuuming.html
Description:
hi i found a tiny error below:
https://www.postgresql.org/docs/current/routine-vacuuming.html
>Drop any old replication slots. Use pg_stat_replication to find slots where
age(xmin) or age(catalog_xmin) is large. In many cases, such slots were
created for replication to servers that no longer exist, or that have been
down for a long time.
not pg_stat_replication but pg_replication_slots
because pg_stat_replication has neither
xmin nor catalog_xmin.
thank you
^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: correction
2025-02-24 06:52 correction PG Doc comments form <noreply@postgresql.org>
@ 2025-02-27 22:57 ` Euler Taveira <euler@eulerto.com>
0 siblings, 0 replies; 20+ messages in thread
From: Euler Taveira @ 2025-02-27 22:57 UTC (permalink / raw)
To: izumi.kuramura@gmail.com; pgsql-docs@lists.postgresql.org
On Mon, Feb 24, 2025, at 3:52 AM, PG Doc comments form wrote:
> hi i found a tiny error below:
> https://www.postgresql.org/docs/current/routine-vacuuming.html
> >Drop any old replication slots. Use pg_stat_replication to find slots where
> age(xmin) or age(catalog_xmin) is large. In many cases, such slots were
> created for replication to servers that no longer exist, or that have been
> down for a long time.
>
> not pg_stat_replication but pg_replication_slots
> because pg_stat_replication has neither
> xmin nor catalog_xmin.
>
Good catch! This seems an oversight in commit a70bce43fbc that was
backpatched down to v14. The attached patch should fix it.
--
Euler Taveira
EDB https://www.enterprisedb.com/
Attachments:
[text/x-patch] doc-fix.patch (1006B, ../../73133eb7-d8ef-4b3f-a9da-c03d12252501@app.fastmail.com/3-doc-fix.patch)
download | inline diff:
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b5b9da7f8a9..27de593a7b8 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -714,8 +714,8 @@ HINT: Execute a database-wide VACUUM in that database.
</listitem>
<listitem>
<simpara>Drop any old replication slots. Use
- <link linkend="monitoring-pg-stat-replication-view">pg_stat_replication</link> to
- find slots where <literal>age(xmin)</literal> or <literal>age(catalog_xmin)</literal>
+ <link linkend="view-pg-replication-slots"><structname>pg_replication_slots</structname></link>
+ to find slots where <literal>age(xmin)</literal> or <literal>age(catalog_xmin)</literal>
is large. In many cases, such slots were created for replication to servers that no
longer exist, or that have been down for a long time. If you drop a slot for a server
that still exists and might still try to connect to that slot, that replica may
^ permalink raw reply [nested|flat] 20+ messages in thread
end of thread, other threads:[~2025-02-27 22:57 UTC | newest]
Thread overview: 20+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2017-11-19 19:38 Correction demirgokhan@gmail.com
2017-11-19 21:17 ` Tom Lane <tgl@sss.pgh.pa.us>
2017-11-21 19:11 ` Gokhan Demir <demirgokhan@gmail.com>
2022-05-11 00:33 correction PG Doc comments form <noreply@postgresql.org>
2022-05-11 10:36 ` Re: correction Laurenz Albe <laurenz.albe@cybertec.at>
2022-05-13 20:36 ` Re: correction Bruce Momjian <bruce@momjian.us>
2022-05-13 21:49 ` Re: correction Laurenz Albe <laurenz.albe@cybertec.at>
2022-05-13 22:16 ` Re: correction David G. Johnston <david.g.johnston@gmail.com>
2022-06-07 21:07 ` Re: correction Bruce Momjian <bruce@momjian.us>
2022-06-07 21:40 ` Re: correction David G. Johnston <david.g.johnston@gmail.com>
2022-06-07 23:51 ` Re: correction Bruce Momjian <bruce@momjian.us>
2022-06-07 23:53 ` Re: correction David G. Johnston <david.g.johnston@gmail.com>
2022-06-08 00:00 ` Re: correction Tom Lane <tgl@sss.pgh.pa.us>
2022-06-08 00:26 ` Re: correction Bruce Momjian <bruce@momjian.us>
2022-06-09 23:18 ` Re: correction David G. Johnston <david.g.johnston@gmail.com>
2022-06-22 18:33 ` Re: correction Bruce Momjian <bruce@momjian.us>
2022-07-22 00:24 Correction PG Doc comments form <noreply@postgresql.org>
2022-07-24 19:39 ` Tom Lane <tgl@sss.pgh.pa.us>
2025-02-24 06:52 correction PG Doc comments form <noreply@postgresql.org>
2025-02-27 22:57 ` Re: correction Euler Taveira <euler@eulerto.com>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox