public inbox for [email protected]help / color / mirror / Atom feed
[PATCH v6 07/10] is vs are plural 4+ messages / 4 participants [nested] [flat]
* [PATCH v6 07/10] is vs are plural @ 2019-04-04 23:57 Justin Pryzby <[email protected]> 0 siblings, 0 replies; 4+ messages in thread From: Justin Pryzby @ 2019-04-04 23:57 UTC (permalink / raw) Should backpatch to v12 --- doc/src/sgml/ref/alter_table.sgml | 2 +- doc/src/sgml/sources.sgml | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/doc/src/sgml/ref/alter_table.sgml b/doc/src/sgml/ref/alter_table.sgml index b2eb7097a9..fa848e0bdf 100644 --- a/doc/src/sgml/ref/alter_table.sgml +++ b/doc/src/sgml/ref/alter_table.sgml @@ -889,7 +889,7 @@ WITH ( MODULUS <replaceable class="parameter">numeric_literal</replaceable>, REM from the parent table will be created in the partition, if they don't already exist. If any of the <literal>CHECK</literal> constraints of the table being - attached is marked <literal>NO INHERIT</literal>, the command will fail; + attached are marked <literal>NO INHERIT</literal>, the command will fail; such constraints must be recreated without the <literal>NO INHERIT</literal> clause. </para> diff --git a/doc/src/sgml/sources.sgml b/doc/src/sgml/sources.sgml index 283c3e0357..12704c6fdf 100644 --- a/doc/src/sgml/sources.sgml +++ b/doc/src/sgml/sources.sgml @@ -466,8 +466,8 @@ Hint: the addendum enough for error messages. Detail and hint messages can be relegated to a verbose mode, or perhaps a pop-up error-details window. Also, details and hints would normally be suppressed from the server log to save - space. Reference to implementation details is best avoided since users - aren't expected to know the details. + space. References to implementation details are best avoided since users + aren't expected to know them. </para> </simplesect> -- 2.17.0 --C+ts3FVlLX8+P6JN Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="v6-0008-doc-backup-manifests.patch" ^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: [PATCH] Allow Postgres to pick an unused port to listen @ 2023-05-08 14:43 Alvaro Herrera <[email protected]> 0 siblings, 1 reply; 4+ messages in thread From: Alvaro Herrera @ 2023-05-08 14:43 UTC (permalink / raw) To: Yurii Rashkovskii <[email protected]>; +Cc: Stephen Frost <[email protected]>; Peter Eisentraut <[email protected]>; Tom Lane <[email protected]>; Robert Haas <[email protected]>; Greg Stark <[email protected]>; Andrew Dunstan <[email protected]>; [email protected]; Cary Huang <[email protected]> On 2023-Apr-19, Yurii Rashkovskii wrote: > If we consider this path, then (if we assume the format of the file is > still to be private), we can make the port line accept multiple ports using > a delimiter like `:` so that the next line still remains the same. This made me wonder if storing the unadorned port number is really the best way. Suppose we did extend things so that we listen on different ports on different interfaces; how would this scheme work at all? I suspect it would be simpler to store both the interface address and the port, perhaps separated by :. You would keep it to one pair per line, so you'd get the IPv6 address/port separately from the IPv4 address, for example. And if you happen to have multiple addresses, you know exactly which ones you're listening on. To match a problem that has been discussed in the lists previously, suppose you have listen_addresses='localhost' and the resolver does funny things with that name (say you mess up /etc/hosts after starting). Things would be much simpler if you knew exactly what the resolver did at postmaster start time. > (I consider this feature so small that it doesn't deserve such a lengthy > discussion. However, I also get Tom's point about how we document this You should see the discussion that led to the addition of psql's 'exit' command sometime: https://www.postgresql.org/message-id/flat/CALVFHFb-C_5_94hueWg6Dd0zu7TfbpT7hzsh9Zf0DEDOSaAnfA%40mai... -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/ "Every machine is a smoke machine if you operate it wrong enough." https://twitter.com/libseybieda/status/1541673325781196801 ^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: [PATCH] Allow Postgres to pick an unused port to listen @ 2023-05-08 14:49 Tom Lane <[email protected]> parent: Alvaro Herrera <[email protected]> 0 siblings, 1 reply; 4+ messages in thread From: Tom Lane @ 2023-05-08 14:49 UTC (permalink / raw) To: Alvaro Herrera <[email protected]>; +Cc: Yurii Rashkovskii <[email protected]>; Stephen Frost <[email protected]>; Peter Eisentraut <[email protected]>; Robert Haas <[email protected]>; Greg Stark <[email protected]>; Andrew Dunstan <[email protected]>; [email protected]; Cary Huang <[email protected]> Alvaro Herrera <[email protected]> writes: > This made me wonder if storing the unadorned port number is really the > best way. Suppose we did extend things so that we listen on different > ports on different interfaces; how would this scheme work at all? Yeah, the probability that that will happen someday is one of the things bothering me about this proposal. I'd rather change the file format to support that first (it can be dummy for now, with all lines showing the same port), and then document it second. regards, tom lane ^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: [PATCH] Allow Postgres to pick an unused port to listen @ 2023-05-11 07:01 Yurii Rashkovskii <[email protected]> parent: Tom Lane <[email protected]> 0 siblings, 0 replies; 4+ messages in thread From: Yurii Rashkovskii @ 2023-05-11 07:01 UTC (permalink / raw) To: Tom Lane <[email protected]>; +Cc: Alvaro Herrera <[email protected]>; Stephen Frost <[email protected]>; Peter Eisentraut <[email protected]>; Robert Haas <[email protected]>; Greg Stark <[email protected]>; Andrew Dunstan <[email protected]>; [email protected]; Cary Huang <[email protected]> Alvaro, Tom, On Mon, May 8, 2023 at 4:49 PM Tom Lane <[email protected]> wrote: > Alvaro Herrera <[email protected]> writes: > > This made me wonder if storing the unadorned port number is really the > > best way. Suppose we did extend things so that we listen on different > > ports on different interfaces; how would this scheme work at all? > > Yeah, the probability that that will happen someday is one of the > things bothering me about this proposal. I'd rather change the > file format to support that first (it can be dummy for now, with > all lines showing the same port), and then document it second. > How soon do you think the change will occur that will allow for choosing different ports on different interfaces? I am happy to help address this. Relying on a variable number of lines may be counter-productive here if we want postmaster.pid to be easily readable by shell scripts. What if we improved the port line to be something like this? ``` 127.0.0.1=5432 ::1=54321 ``` Basically, a space-delimited set of address/port pairs (delimited by `=` to allow IPv6 addresses to use a colon). If we allow the address side to be dropped, the current format (`5432`) will also be correct parsing-wise. -- Y. ^ permalink raw reply [nested|flat] 4+ messages in thread
end of thread, other threads:[~2023-05-11 07:01 UTC | newest] Thread overview: 4+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2019-04-04 23:57 [PATCH v6 07/10] is vs are plural Justin Pryzby <[email protected]> 2023-05-08 14:43 Re: [PATCH] Allow Postgres to pick an unused port to listen Alvaro Herrera <[email protected]> 2023-05-08 14:49 ` Re: [PATCH] Allow Postgres to pick an unused port to listen Tom Lane <[email protected]> 2023-05-11 07:01 ` Re: [PATCH] Allow Postgres to pick an unused port to listen Yurii Rashkovskii <[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