Re: small clairifcation
On Thu, Aug 27, 2020 at 6:17 PM Tom Lane wrote: > PG Doc comments form writes: > > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/9.5/ssh-tunnels.html > > Description: > > > "The first number in the -L argument, 6, is the port number of your > end > > of the tunnel; it can be any unused port. (IANA reserves ports 49152 > through > > 65535 for private use.) The second number, 5432, is the remote end of the > > tunnel: the port number your server is using. " > > > as a beginner This took me some time to understand what do you mean by > "your > > server" "your end of the tunnel " > > Hm, do you have a suggestion for better wording? > > I agree on the need for a different perspective here since it reads just fine once you know what it is talking about. But absent that maybe a slightly more tutorial flow would be good. ``` First make sure you can connect to the remote machine that is able to access the PostgreSQL server (in this example the PostgreSQL server is running on said remote machine). local> ssh j...@foo.com Once connected, confirm that while on that machine you are able to connect to the PostgreSQL server via psql. remote> psql -h localhost -p 5432 postgres Now that we have confirmed that the two seperate parts are working, the ssh connection and the psql connection, we can create a tunnel so that we can execute psql on our local machine but have the PostgreSQL server see the inbound connection as coming from the remote machine. To do this we need to set up a server-like process on the local machine to accept the connection from psql and then transmit the data to the remote machine. Since psql is looking for a port number to connect to, 5432 when executed on the remote machine, we need to specify which one to use on the local machine. For this example we choose 6 (it can be any number between 49152 and 65535, and must not be in use already [footnote if more detail is desired]). We are, in effect, merging the ssh and psql commands above into a hybrid command that maps the remote psql location information to a local address and port. ssh, in this tunnel mode, always just listens to its loopback address so only the local port (6333) is required; but both the remote host (which is using its own loopback address - the localhost thus refers to this) and port (5432) are needed as that end of the tunnel can point anywhere visible to the remote machine (foo.com). local> ssh -L 6:localhost:5432 j...@foo.com Now we locally launch psql, connecting to localhost:6, and ssh on foo.com proxies the stream to its localhost:5432 connection. local> psql -h localhost -p 6 ``` I haven't considered how or whether the more advanced details would change if we expand upon and reword the basic section to be more like the above. I am curious about whether and why this method absolutely guarantees that the resultant connection within the tunnel is not SSL-encrypted. David J.
Re: small clairifcation
PG Doc comments form writes: > The following documentation comment has been logged on the website: > Page: https://www.postgresql.org/docs/9.5/ssh-tunnels.html > Description: > "The first number in the -L argument, 6, is the port number of your end > of the tunnel; it can be any unused port. (IANA reserves ports 49152 through > 65535 for private use.) The second number, 5432, is the remote end of the > tunnel: the port number your server is using. " > as a beginner This took me some time to understand what do you mean by "your > server" "your end of the tunnel " Hm, do you have a suggestion for better wording? regards, tom lane
Re: Document "59.2. Built-in Operator Classes" have a clerical error?
Alvaro Herrera writes: > On 2020-Aug-27, Michael Paquier wrote: >> This leads me to the updated version attached. BRIN has 29 different >> opclasses, visibly. > I checked both HTML and PDF and it looks good to me to commit. I did not verify that the correct operators are listed, but visually it looks OK. One thing I've noted in working with this stuff is that (at least for me) HTML seems to default to valign=center while PDF defaults to valign=top. You can see that in these tables in the positioning of the opclass names. For myself, valign=center looks better in these cases so I'd suggest adding s to force it that way. Or, if you like valign=top, we should do that --- but it ought to be consistent across output formats. > As a subsequent improvement we could discuss tweak the stylesheets to > change the column widths in PDF, but I don't think we need to stall this > patch for that, since it's a much smaller issue IMV. Yeah, I think some fooling with the column widths could improve the PDF results, but it's a minor point. regards, tom lane
small clairifcation
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/9.5/ssh-tunnels.html Description: "The first number in the -L argument, 6, is the port number of your end of the tunnel; it can be any unused port. (IANA reserves ports 49152 through 65535 for private use.) The second number, 5432, is the remote end of the tunnel: the port number your server is using. " as a beginner This took me some time to understand what do you mean by "your server" "your end of the tunnel "
Re: Document "59.2. Built-in Operator Classes" have a clerical error?
On 2020-Aug-27, Michael Paquier wrote: > This leads me to the updated version attached. BRIN has 29 different > opclasses, visibly. I checked both HTML and PDF and it looks good to me to commit. As a subsequent improvement we could discuss tweak the stylesheets to change the column widths in PDF, but I don't think we need to stall this patch for that, since it's a much smaller issue IMV. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
PG_Basebackup not compatible with the version 12.3
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/12/app-pgbasebackup.html Description: PG_Basebackup not compatible with the version 12.3
Re: Document "59.2. Built-in Operator Classes" have a clerical error?
On Wed, Aug 26, 2020 at 07:19:09PM -0400, Tom Lane wrote:
> With one eye on the PDF width issue, I propose that we not draw
> the distinction, but just list all the relevant operators for each
> opclass (its native ones, plus the applicable "loose" operators).
> Then we only need two columns, opclass and operators.
Indeed, removing the types makes sense if we list them with the
operators. I have been looking at your suggestions, and adding a
space before the first parenthesis where the types are listed sounds
good to me, but I am not sure that it is a good idea to add spaces
between each type. Looking at the pdf produced, I think that we
should also drop entirely colspec for the BRIN table as it gets much
small in width once the data type column is removed. I also looked at
rowsep for the PDF, and I tend to prefer the version where we separate
each cell for the operator, as a matter of readability.
This leads me to the updated version attached. BRIN has 29 different
opclasses, visibly.
--
Michael
diff --git a/doc/src/sgml/brin.sgml b/doc/src/sgml/brin.sgml
index b9d596e3c4..c3298ed92b 100644
--- a/doc/src/sgml/brin.sgml
+++ b/doc/src/sgml/brin.sgml
@@ -120,354 +120,293 @@ LOG: request for BRIN range summarization for index "brin_wi_idx" page 128 was
Built-in BRIN Operator Classes
-
-
-
-
+
Name
- Indexed Data Type
Indexable Operators
- int8_minmax_ops
- bigint
-
-
- =
- =
- =
-
-
+ range_inclusion_ops
+ = (anyrange,anyrange)
+ (anyrange,anyrange)
+= (anyrange,anyrange)
+= (anyrange,anyrange)
+ (anyrange,anyrange)
+ (anyrange,anyrange)
+@ (anyrange,anyelement)
+@ (anyrange,anyrange)
+@ (anyrange,anyrange)
+ (anyrange,anyrange)
+ (anyrange,anyrange)
+ (anyrange,anyrange)
+ (anyrange,anyrange)
+-|- (anyrange,anyrange)
+
- bit_minmax_ops
- bit
-
-
- =
- =
- =
-
-
+ bit_minmax_ops
+ = (bit,bit)
+ (bit,bit)
+ (bit,bit)
+= (bit,bit)
+= (bit,bit)
+
- varbit_minmax_ops
- bit varying
-
-
- =
- =
- =
-
-
+ varbit_minmax_ops
+ = (varbit,varbit)
+ (varbit,varbit)
+ (varbit,varbit)
+= (varbit,varbit)
+= (varbit,varbit)
+
- box_inclusion_ops
- box
-
-
-
-
-
-
- ~=
- @
- @
- |
- |
- |
- |
-
+ box_inclusion_ops
+ @ (box,point)
+ (box,box)
+ (box,box)
+ (box,box)
+ (box,box)
+@ (box,box)
+@ (box,box)
+~= (box,box)
+ (box,box)
+| (box,box)
+| (box,box)
+| (box,box)
+| (box,box)
+
- bytea_minmax_ops
- bytea
-
-
- =
- =
- =
-
-
+ bpchar_minmax_ops
+ = (character,character)
+ (character,character)
+= (character,character)
+ (character,character)
+= (character,character)
+
- bpchar_minmax_ops
- character
-
-
- =
- =
- =
-
-
+ bytea_minmax_ops
+ = (bytea,bytea)
+ (bytea,bytea)
+= (bytea,bytea)
+ (bytea,bytea)
+= (bytea,bytea)
+
- char_minmax_ops
- "char"
-
-
- =
- =
- =
-
-
+ char_minmax_ops
+ = ("char","char")
+ ("char","char")
+= ("char","char")
+ ("char","char")
+= ("char","char")
+
- date_minmax_ops
- date
-
-
- =
- =
- =
-
-
+ date_minmax_ops
+ = (date,date)
+ (date,date)
+= (date,date)
+ (date,date)
+= (date,date)
+
- float8_minmax_ops
- double precision
-
-
- =
- =
- =
-
-
+ float4_minmax_ops
+ = (float4,float4)
+ (float4,float4)
+ (float4,float4)
+= (float4,float4)
+= (float4,float4)
+
- inet_minmax_ops
- inet
-
-
- =
- =
- =
-
-
+ float8_minmax_ops
+ = (float8,float8)
+ (float8,float8)
+= (float8,float8)
+ (float8,float8)
+= (float8,float8)
+
- network_inclusion_ops
- inet
-
-
- =
- =
- =
-
-
-
+ inet_inclusion_ops
+ (inet,inet)
+= (inet,inet)
+ (inet,inet)
+= (inet,inet)
+= (inet,inet)
+ (inet,inet)
+
- int4_minmax_ops
- integer
-
-
- =
- =
- =
-
-
+ inet_minmax_ops
+ = (inet,inet)
+ (inet,inet)
+= (inet,inet)
+ (inet,inet)
+= (inet,inet)
+
- interval_minmax_ops
- interval
-
-
- =
- =
- =
-
-
+ int2_minmax_ops
+ = (int2,int2)
+ (int2,int2)
+ (int2,int2)
+= (int2,int2)
+= (int2,int2)
+
-
