Update to reflect that TLS1 and TLSv1.1 are now deprecated

[Daniel Gustafsson]

The recently published RFC 8996 deprecates the use of TLSv1 and TLSv1.1, the
attached rewords where we say our default of 1.2 is industry best practice with
a link to the authoritative source.

--
Daniel Gustafsson   https://vmware.com/



rfc_8996.diff
Description: Binary data

Re: Update to reflect that TLS1 and TLSv1.1 are now deprecated

[Jonathan S. Katz]

On 3/24/21 5:49 AM, Daniel Gustafsson wrote:
> The recently published RFC 8996 deprecates the use of TLSv1 and TLSv1.1, the
> attached rewords where we say our default of 1.2 is industry best practice 
> with
> a link to the authoritative source.

I would s/as of/stated in/ and add a comma after RFC 8996, but otherwise
+1 from me.

Jonathan



OpenPGP_signature
Description: OpenPGP digital signature

Logical replication restart position (restart_lsn)

[PG Doc comments form]

The following documentation comment has been logged on the website:

Page: https://www.postgresql.org/docs/10/warm-standby.html
Description:

Hi, I was struggling to understand why my logical replication clients (using
the wal2json plugin) are not advancing the restart_lsn as much as I
expected. E.g. I regularly see restart_lsn becoming 1GB or more behind
confirmed_flush_lsn, but it always catches up eventually (within an hour).

The documentation doesn't seem to explain why this can happen, only that
"restart_lsn [is] The address (LSN) of oldest WAL which still might be
required by the consumer of this slot and thus won't be automatically
removed during checkpoints..."
. 

We are advised to monitor logical replication in a similar way to physical
replication (e.g. using pg_replication_slots)
,
presumably to avoid infinite WAL buildup and exhausting disk space on the
master. (And similarly, "An important health indicator of streaming
replication is the amount of WAL records generated in the primary, but not
yet applied in the standby.") However, no advice about monitoring
restart_lsn is given, or reasonable levels of restart lag.

I found a discussion on pgsql-hackers

where participants said:

"In our observation via PSQL the advance command as well do not move the
restart_lsn immediately."

"The restart_lsn is lsn required by the oldest txn." 

"even though we update confirmed_flush_lsn every time with the new value but
restart_lsn is updated only when candidate_restart_valid has a valid value
each time after a call to LogicalConfirmReceivedLocation. We
update candidate_restart_valid in LogicalIncreaseRestartDecodingForSlot
which is called only during decoding of XLOG_RUNNING_XACTS record."

The comment "The restart_lsn is lsn required by the oldest txn" doesn't seem
to be exactly true, as I have seen the restart_lsn pointing to snapshots
with running transactions, such as this one:

rmgr: Standby len (rec/tot): 54/54, tx:  0, lsn:
E3A/912B8030, prev E3A/912B7F50, desc: RUNNING_XACTS nextXid 487077663
latestCompletedXid 487
077661 oldestRunningXid 487077662; 1 xacts: 487077662

However, I also found that "[a snapshot] has room for at most 64 non-aborted
subtransactions per session. If there are more than 64 such subtransactions,
the snapshot is marked as suboverflowed. A suboverflowed snapshot does not
contain all data required to determine visibility, so PostgreSQL will
occasionally have to resort to pg_subtrans."

(Which is not possible after a server crash, since pg_subtrans is discarded,
hence a suboverflowed transaction cannot be a valid restart point?)

Therefore, I surmise that restart_lsn must point to a RUNNING_XACTS WAL
record (a snapshot?) which is not suboverflowed (does not have the "subxid
ovf" flag), and thus the restart_lsn will point to the most recent such
record before the client's confirmed_flush_lsn. From observation that also
appears to be the case.

If this is correct, I think it would be great if it was in the official
documentation. Perhaps something like this on the pg_replication_slots page?


"The address (LSN) of oldest WAL which still might be required by the
consumer of this slot and thus won't be automatically removed during
checkpoints. Postgres always restart replication from the most recent
snapshot WAL record which is not suboverflowed, before the
confirmed_flush_lsn, which could be significantly behind if there are many
subtransactions running. Clients can request (on connection) that decoding
start from a later LSN (see
https://www.postgresql.org/docs/10/logicaldecoding-explanation.html#LOGICALDECODING-REPLICATION-SLOTS)."

Or perhaps this information could be added under "48.2.2. Replication
Slots", with just a link from the restart_lsn entry?

Thanks, Chris.

Re: "there is no way to insert less than one row"

[Peter Eisentraut]

On 20.03.21 20:16, PG Doc comments form wrote:

So, the last insert command inserted zero rows. What is meant by "there is
no way to insert less than one row"?


I think the point was that you can't insert partial rows.

Re: Update to reflect that TLS1 and TLSv1.1 are now deprecated

[Peter Eisentraut]

On 24.03.21 10:49, Daniel Gustafsson wrote:

The recently published RFC 8996 deprecates the use of TLSv1 and TLSv1.1, the
attached rewords where we say our default of 1.2 is industry best practice with
a link to the authoritative source.


The "industry best practices" the original text refers to are things 
like PCI-DSS and various announcements by browser vendors.  Those best 
practices have already been around for long before RFC 8996.  I think 
this patch is mangling the two concepts of what is best practice and 
what is officially deprecated, and since when each of them applies.


If we want to throw RFC 8996 into the mix, we could drop the reference 
to best practices and just write something like


"The default is TLSv1.2.  Note that all older versions are deprecated as 
of this writing (see RFC 8996)."


However, now that I read this, it's not clear from this who is doing the 
deprecating.  Someone could wonder, does this mean PostgreSQL will drop 
support for it?


Maybe the old wording is best and more timeless, and if someone wants to 
question it they can do their own research.

Re: Update to reflect that TLS1 and TLSv1.1 are now deprecated

[Daniel Gustafsson]

> On 24 Mar 2021, at 21:07, Peter Eisentraut 
>  wrote:
> 
> On 24.03.21 10:49, Daniel Gustafsson wrote:
>> The recently published RFC 8996 deprecates the use of TLSv1 and TLSv1.1, the
>> attached rewords where we say our default of 1.2 is industry best practice 
>> with
>> a link to the authoritative source.
> 
> The "industry best practices" the original text refers to are things like 
> PCI-DSS and various announcements by browser vendors.  Those best practices 
> have already been around for long before RFC 8996.  I think this patch is 
> mangling the two concepts of what is best practice and what is officially 
> deprecated, and since when each of them applies.

Well, since the publishing of RFC 8996 as a BCP document the industry best
practice is to not allow TLSv1.0 or TLSv1.1 at all, so claiming 1.2 as the
default with others available being best practice is concept mangling to some
extent as well.

> However, now that I read this, it's not clear from this who is doing the 
> deprecating.  Someone could wonder, does this mean PostgreSQL will drop 
> support for it?

OpenSSL and/or distributions are likely to beat us to it, so users may find
their servers unreachable after upgrading OpenSSL because of the protocol no
longer being available.  Maybe it's the below wording which should reflect that
all versions of OpenSSL will restrict the available protocols, either because
of age or RFC 8996?

"Older versions of the OpenSSL library do not support all values; an
error will be raised if an unsupported setting is chosen."

--
Daniel Gustafsson   https://vmware.com/

Re: "there is no way to insert less than one row"

[David G. Johnston]

On Wed, Mar 24, 2021 at 1:29 PM Peter Eisentraut <
peter.eisentr...@enterprisedb.com> wrote:

> On 20.03.21 20:16, PG Doc comments form wrote:
> > So, the last insert command inserted zero rows. What is meant by "there
> is
> > no way to insert less than one row"?
>
> I think the point was that you can't insert partial rows.
>

Sure, if you think its related to the following sentence.  If you think its
related to the subsequent one it means "cannot insert zero rows".  Frankly,
both interpretations are wrong, inserting an explicit column list with
omitted columns populated using defaults is a "partial row API" for
inserting data.

I'm also not fond of the word "conceptually" here - its actually a physical
reality that regardless of how one or more rows are supplied they are
inserted one-at-a-time so far as constraints, discussed in the previous
chapter, are concerned (though some constraints can be deferred).

David J.

TLS acronym

[Daniel Gustafsson]

As discussed in the NSS thread, we've had TLS defined as an  since
commit c6763156589 in 2014 without actually having it defined in acronyms.sgml.

The attached adds the definition linking to the Wikipedia entry for TLS.

--
Daniel Gustafsson   https://vmware.com/



tls_acronym.patch
Description: Binary data

Re: "there is no way to insert less than one row"

[Alvaro Herrera]

On 2021-Mar-24, David G. Johnston wrote:

> On Wed, Mar 24, 2021 at 1:29 PM Peter Eisentraut <
> peter.eisentr...@enterprisedb.com> wrote:
> 
> > On 20.03.21 20:16, PG Doc comments form wrote:
> > > So, the last insert command inserted zero rows. What is meant by "there
> > is
> > > no way to insert less than one row"?
> >
> > I think the point was that you can't insert partial rows.
> 
> Sure, if you think its related to the following sentence.  If you think its
> related to the subsequent one it means "cannot insert zero rows".  Frankly,
> both interpretations are wrong, inserting an explicit column list with
> omitted columns populated using defaults is a "partial row API" for
> inserting data.

Not really -- what you're doing in that case is insert a row that has
some null columns.  It is still a complete row.  I'm with Peter: the
idea being conveyed is that in tables, rows are atomic units.

> I'm also not fond of the word "conceptually" here - its actually a physical
> reality that regardless of how one or more rows are supplied they are
> inserted one-at-a-time so far as constraints, discussed in the previous
> chapter, are concerned (though some constraints can be deferred).

That doesn't seem a very interesting distinction, but I agree that this
can be worded differently to convey the idea of rows being the basic
units more clearly.  Maybe something like this:

: When a table is created, it contains no data. The first thing to do
: before a database can be of much use is to insert data. Data is
: inserted one row at a time. Of course you can also insert
: more than one row in a single command, but it is not possible to
: insert something that is not a complete row.
: Even if you know only some column values, a complete row is created.

The next paragraphs explain that omitted columns are defaulted, which
IMO flows neatly from here.


(I would substitute "Of course you can also" with "It is possible to" ...
though that results in repetition of the word "possible" ... hmm.)

-- 
Álvaro Herrera39°49'30"S 73°17'W

Re: TLS acronym

[Michael Paquier]

On Thu, Mar 25, 2021 at 12:19:36AM +0100, Daniel Gustafsson wrote:
> As discussed in the NSS thread, we've had TLS defined as an  since
> commit c6763156589 in 2014 without actually having it defined in 
> acronyms.sgml.
> 
> The attached adds the definition linking to the Wikipedia entry for TLS.

Sounds like a good idea to me.  Thanks!
--
Michael


signature.asc
Description: PGP signature