public inbox for [email protected]help / color / mirror / Atom feed
correction 13+ messages / 5 participants [nested] [flat]
* correction @ 2022-05-11 00:33 PG Doc comments form <[email protected]> 0 siblings, 1 reply; 13+ messages in thread From: PG Doc comments form @ 2022-05-11 00:33 UTC (permalink / raw) To: [email protected]; +Cc: [email protected] 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] 13+ messages in thread
* Re: correction @ 2022-05-11 10:36 Laurenz Albe <[email protected]> parent: PG Doc comments form <[email protected]> 0 siblings, 1 reply; 13+ messages in thread From: Laurenz Albe @ 2022-05-11 10:36 UTC (permalink / raw) To: [email protected]; [email protected] 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] 13+ messages in thread
* Re: correction @ 2022-05-13 20:36 Bruce Momjian <[email protected]> parent: Laurenz Albe <[email protected]> 0 siblings, 1 reply; 13+ messages in thread From: Bruce Momjian @ 2022-05-13 20:36 UTC (permalink / raw) To: Laurenz Albe <[email protected]>; +Cc: [email protected]; [email protected] 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 <[email protected]> https://momjian.us EDB https://enterprisedb.com Indecision is a decision. Inaction is an action. Mark Batterson Attachments: [text/x-diff] strict.diff (732B, 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] 13+ messages in thread
* Re: correction @ 2022-05-13 21:49 Laurenz Albe <[email protected]> parent: Bruce Momjian <[email protected]> 0 siblings, 2 replies; 13+ messages in thread From: Laurenz Albe @ 2022-05-13 21:49 UTC (permalink / raw) To: Bruce Momjian <[email protected]>; +Cc: [email protected]; [email protected] 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] 13+ messages in thread
* Re: correction @ 2022-05-13 22:16 David G. Johnston <[email protected]> parent: Laurenz Albe <[email protected]> 1 sibling, 0 replies; 13+ messages in thread From: David G. Johnston @ 2022-05-13 22:16 UTC (permalink / raw) To: Laurenz Albe <[email protected]>; +Cc: Bruce Momjian <[email protected]>; [email protected]; Pg Docs <[email protected]> On Fri, May 13, 2022 at 2:49 PM Laurenz Albe <[email protected]> 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, 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] 13+ messages in thread
* Re: correction @ 2022-06-07 21:07 Bruce Momjian <[email protected]> parent: Laurenz Albe <[email protected]> 1 sibling, 1 reply; 13+ messages in thread From: Bruce Momjian @ 2022-06-07 21:07 UTC (permalink / raw) To: Laurenz Albe <[email protected]>; +Cc: [email protected]; [email protected] 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 <[email protected]> https://momjian.us EDB https://enterprisedb.com Indecision is a decision. Inaction is an action. Mark Batterson Attachments: [text/x-diff] strict.diff (838B, 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] 13+ messages in thread
* Re: correction @ 2022-06-07 21:40 David G. Johnston <[email protected]> parent: Bruce Momjian <[email protected]> 0 siblings, 1 reply; 13+ messages in thread From: David G. Johnston @ 2022-06-07 21:40 UTC (permalink / raw) To: Bruce Momjian <[email protected]>; +Cc: Laurenz Albe <[email protected]>; [email protected]; Pg Docs <[email protected]> On Tue, Jun 7, 2022 at 2:07 PM Bruce Momjian <[email protected]> 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] 13+ messages in thread
* Re: correction @ 2022-06-07 23:51 Bruce Momjian <[email protected]> parent: David G. Johnston <[email protected]> 0 siblings, 3 replies; 13+ messages in thread From: Bruce Momjian @ 2022-06-07 23:51 UTC (permalink / raw) To: David G. Johnston <[email protected]>; +Cc: Laurenz Albe <[email protected]>; [email protected]; Pg Docs <[email protected]> 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 <[email protected]> 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 <[email protected]> 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, 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] 13+ messages in thread
* Re: correction @ 2022-06-07 23:53 David G. Johnston <[email protected]> parent: Bruce Momjian <[email protected]> 2 siblings, 0 replies; 13+ messages in thread From: David G. Johnston @ 2022-06-07 23:53 UTC (permalink / raw) To: Bruce Momjian <[email protected]>; +Cc: Laurenz Albe <[email protected]>; [email protected]; Pg Docs <[email protected]> On Tue, Jun 7, 2022 at 4:51 PM Bruce Momjian <[email protected]> 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 <[email protected]> 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] 13+ messages in thread
* Re: correction @ 2022-06-08 00:00 Tom Lane <[email protected]> parent: Bruce Momjian <[email protected]> 2 siblings, 1 reply; 13+ messages in thread From: Tom Lane @ 2022-06-08 00:00 UTC (permalink / raw) To: Bruce Momjian <[email protected]>; +Cc: David G. Johnston <[email protected]>; Laurenz Albe <[email protected]>; [email protected]; Pg Docs <[email protected]> Bruce Momjian <[email protected]> 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] 13+ messages in thread
* Re: correction @ 2022-06-08 00:26 Bruce Momjian <[email protected]> parent: Tom Lane <[email protected]> 0 siblings, 1 reply; 13+ messages in thread From: Bruce Momjian @ 2022-06-08 00:26 UTC (permalink / raw) To: Tom Lane <[email protected]>; +Cc: David G. Johnston <[email protected]>; Laurenz Albe <[email protected]>; [email protected]; Pg Docs <[email protected]> On Tue, Jun 7, 2022 at 08:00:16PM -0400, Tom Lane wrote: > Bruce Momjian <[email protected]> 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 <[email protected]> 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, 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] 13+ messages in thread
* Re: correction @ 2022-06-09 23:18 David G. Johnston <[email protected]> parent: Bruce Momjian <[email protected]> 0 siblings, 0 replies; 13+ messages in thread From: David G. Johnston @ 2022-06-09 23:18 UTC (permalink / raw) To: Bruce Momjian <[email protected]>; +Cc: Tom Lane <[email protected]>; Laurenz Albe <[email protected]>; [email protected]; Pg Docs <[email protected]> On Tue, Jun 7, 2022 at 5:26 PM Bruce Momjian <[email protected]> wrote: > On Tue, Jun 7, 2022 at 08:00:16PM -0400, Tom Lane wrote: > > Bruce Momjian <[email protected]> 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] 13+ messages in thread
* Re: correction @ 2022-06-22 18:33 Bruce Momjian <[email protected]> parent: Bruce Momjian <[email protected]> 2 siblings, 0 replies; 13+ messages in thread From: Bruce Momjian @ 2022-06-22 18:33 UTC (permalink / raw) To: David G. Johnston <[email protected]>; +Cc: Laurenz Albe <[email protected]>; [email protected]; Pg Docs <[email protected]> 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 <[email protected]> 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 <[email protected]> https://momjian.us EDB https://enterprisedb.com Indecision is a decision. Inaction is an action. Mark Batterson ^ permalink raw reply [nested|flat] 13+ messages in thread
end of thread, other threads:[~2022-06-22 18:33 UTC | newest] Thread overview: 13+ messages (download: mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2022-05-11 00:33 correction PG Doc comments form <[email protected]> 2022-05-11 10:36 ` Laurenz Albe <[email protected]> 2022-05-13 20:36 ` Bruce Momjian <[email protected]> 2022-05-13 21:49 ` Laurenz Albe <[email protected]> 2022-05-13 22:16 ` David G. Johnston <[email protected]> 2022-06-07 21:07 ` Bruce Momjian <[email protected]> 2022-06-07 21:40 ` David G. Johnston <[email protected]> 2022-06-07 23:51 ` Bruce Momjian <[email protected]> 2022-06-07 23:53 ` David G. Johnston <[email protected]> 2022-06-08 00:00 ` Tom Lane <[email protected]> 2022-06-08 00:26 ` Bruce Momjian <[email protected]> 2022-06-09 23:18 ` David G. Johnston <[email protected]> 2022-06-22 18:33 ` Bruce Momjian <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox