public inbox for [email protected]  
help / color / mirror / Atom feed
[PATCH v6 05/15] Improve sentences in overview of system configuration parameters
2+ messages / 2 participants
[nested] [flat]

* [PATCH v6 05/15] Improve sentences in overview of system configuration parameters
@ 2023-09-25 20:32  Karl O. Pinc <[email protected]>
  0 siblings, 0 replies; 2+ messages in thread

From: Karl O. Pinc @ 2023-09-25 20:32 UTC (permalink / raw)

Get rid of "we" wording.  Remove extra words in sentences.

Line break after end of each sentence to ease future patch reading.
---
 doc/src/sgml/config.sgml | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index 6bc1b215db..97f9838bfb 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -10,9 +10,10 @@
 
   <para>
    There are many configuration parameters that affect the behavior of
-   the database system. In the first section of this chapter we
-   describe how to interact with configuration parameters. The subsequent sections
-   discuss each parameter in detail.
+   the database system.
+   The first section of this chapter describes how to interact with
+   configuration parameters.
+   Subsequent sections discuss each parameter in detail.
   </para>
 
   <sect1 id="config-setting">
-- 
2.30.2


--MP_/74urtnrsBSymuH7bJczNOGS
Content-Type: text/x-patch
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename=v6-0006-Provide-examples-of-listing-all-settings.patch



^ permalink  raw  reply  [nested|flat] 2+ messages in thread

* Re: Changing shared_buffers without restart
@ 2024-11-29 01:42  Tom Lane <[email protected]>
  0 siblings, 0 replies; 2+ messages in thread

From: Tom Lane @ 2024-11-29 01:42 UTC (permalink / raw)
  To: Matthias van de Meent <[email protected]>; +Cc: Robert Haas <[email protected]>; Dmitry Dolgov <[email protected]>; pgsql-hackers

Matthias van de Meent <[email protected]> writes:
> I mean, we can do the following to get a nice contiguous empty address
> space no other mmap(NULL)s will get put into:

>     /* reserve size bytes of memory */
>     base = mmap(NULL, size, PROT_NONE, ...flags, ...);
>     /* use the first small_size bytes of that reservation */
>     allocated_in_reserved = mmap(base, small_size, PROT_READ |
> PROT_WRITE, MAP_FIXED, ...);

> With the PROT_NONE protection option the OS doesn't actually allocate
> any backing memory, but guarantees no other mmap(NULL, ...) will get
> placed in that area such that it overlaps with that allocation until
> the area is munmap-ed, thus allowing us to reserve a chunk of address
> space without actually using (much) memory.

Well, that's all great if it works portably.  But I don't see one word
in either POSIX or the Linux mmap(2) man page that promises those
semantics for PROT_NONE.  I also wonder how well a giant chunk of
"unbacked" address space will interoperate with the OOM killer,
top(1)'s display of used memory, and other things that have caused us
headaches with large shared-memory arenas.

Maybe those issues are all in the past and this'll work great.
I'm not holding my breath though.

			regards, tom lane






^ permalink  raw  reply  [nested|flat] 2+ messages in thread


end of thread, other threads:[~2024-11-29 01:42 UTC | newest]

Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2023-09-25 20:32 [PATCH v6 05/15] Improve sentences in overview of system configuration parameters Karl O. Pinc <[email protected]>
2024-11-29 01:42 Re: Changing shared_buffers without restart Tom Lane <[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