Subject: shared_buffers and shmmax

From: dx k9 <[email-masked]>
Date: Tue, 22 Jul 2008 09:39:57 -0400

Hi,
I'm trying to understand what the documentation means by bytes per increment, what is the increment supposed to be bytes, MB, or Kb.  I have my shared_buffers set to 577 MB(4 instances) and I'm multiplying by 8400 bytes.  I would think I would want to keep everything in bytes and not mulitply bytes times MB, but this is what table 17-2 implies.  If I convert 577 to bytes and multiply, my calculator goes exponential on me. I'm going through this table and adding up to see what my shmmax should be (it's 7.5 GB) out of a total memory of 16 GB with 1000 max_connections right now.  What should I use as the "increment" value in regards to shared buffers, 577, 590848 or 605028352 ? 
 
a) 577 MB (This seems too small)
b) 590,848 Kb (this seems just right)
c) 605,028,352 bytes  (this seems too big, I hope it's not c)
 
Thanks,
~DjK
 
Table 17-2. Configuration parameters affecting PostgreSQL's shared memory usage

Name
Approximate multiplier (bytes per increment) as of 8.3

max_connections
1800 + 270 * max_locks_per_transaction

autovacuum_max_workers
1800 + 270 * max_locks_per_transaction

max_prepared_transactions
770 + 270 * max_locks_per_transaction

shared_buffers
8400 (assuming 8 kB BLCKSZ)

wal_buffers
8200 (assuming 8 kB XLOG_BLCKSZ)

max_fsm_relations
70

max_fsm_pages
6

Fixed space requirements
770 kB
_________________________________________________________________
Stay in touch when you're away with Windows Live Messenger.
http://www.windowslive.com/messenger/overview.html?ocid=TXT_TAGLM_WL_messenger2_072008

---

From: Valentin Bogdanov <[email-masked]>
Date: Tue, 22 Jul 2008 14:08:32 +0000 (GMT)

shared_buffers is in disk block size, typically 8K, at least that's what it is on Linux platforms. shmmax is quite simply in bytes.

The default shared_buffer of a 1000 is quite conservative. A good starting value is something like 15-25 percent of your main memory or so I am being told. It really depends on how the machine you have your database on is being used. If postgres is the only application using your box then you can even set this to 80% of the memory. You're fine as long as postgres does not have to resort to using the swap space.

If you set shared_buffers so high that it doesn't agree with your systems shmmax then postgres will give you the required value on startup.

Regards,

Val

--- On Tue, 22/7/08, dx k9 <[email-masked]> wrote:

> From: dx k9 <[email-masked]>
> Subject: [ADMIN] shared_buffers and shmmax
> To: "posgres support" <[email-masked]>
> Date: Tuesday, 22 July, 2008, 2:39 PM
> Hi,
> I'm trying to understand what the documentation means
> by bytes per increment, what is the increment supposed to
> be bytes, MB, or Kb.  I have my shared_buffers set to 577
> MB(4 instances) and I'm multiplying by 8400 bytes.  I
> would think I would want to keep everything in bytes and
> not mulitply bytes times MB, but this is what table 17-2
> implies.  If I convert 577 to bytes and multiply, my
> calculator goes exponential on me. I'm going through
> this table and adding up to see what my shmmax should be
> (it's 7.5 GB) out of a total memory of 16 GB with 1000
> max_connections right now.  What should I use as the
> "increment" value in regards to shared buffers,
> 577, 590848 or 605028352 ? 
>  

      __________________________________________________________
Not happy with your email address?.
Get the one you really want - millions of new email addresses available now at Yahoo! http://uk.docs.yahoo.com/ymail/new.html

---

From: Tom Lane <[email-masked]>
Date: Tue, 22 Jul 2008 10:45:59 -0400

[ redirecting to pgsql-docs ]

Valentin Bogdanov <[email-masked]> writes:
>> be bytes, MB, or Kb.

> shared_buffers is in disk block size, typically 8K, at least that's what it is on Linux platforms. shmmax is quite simply in bytes.

The table the OP is looking at (table 17.2 in the 8.3 docs) predates
the ability to specify shared_buffers in KB or MB instead of
number-of-buffers.  I agree it's not entirely obvious that what it
means is "multiply your setting in KB/MB by 8400/8192".  Anybody have
an idea how to clarify things?

			regards, tom lane

---

From: "Francisco Reyes" <[email-masked]>
Date: Tue, 22 Jul 2008 15:30:21 -0400

> an idea how to clarify things?

Perhaps changing the table title?
Table 17-2. Configuration parameters affecting PostgreSQL's shared memory
usage when not using a size modified.

Alternatively, below the table we could have clarifications such as:
Previously, it was not possible to indicate a size modified such as M for
Megabytes. As of version X.Y, Postgresql allows to use M, for MB, GB for GB
and more... See.... for all values.

When not using one of the new modifiers the space used would be the number
you enter times the constant on the right side of the table.
For example using 100 shared_buffers would be 100 x 8400  = 840,000 bytes.

---

From: "Greg Sabino Mullane" <[email-masked]>
Date: Thu, 24 Jul 2008 17:54:31 -0000

NotDashEscaped: You need GnuPG to verify this message

>> shared_buffers is in disk block size, typically 8K

> an idea how to clarify things?

Bite the bullet and start showing the buffer settings as a pure number of bytes
everywhere, and get rid of the confusing '8kB' unit in pg_settings? Things like
this don't help our cause:

test=# show shared_buffers;
 shared_buffers
----------------
 24MB
(1 row)

test=# set temp_buffers = '24MB';
SET

test=# show temp_buffers;
 temp_buffers
--------------
 3072

test=# select name, setting from pg_settings where name ~ 'buffers';
      name      | setting
----------------+---------
 shared_buffers | 3072
 temp_buffers   | 3072
 wal_buffers    | 8

test=# show wal_buffers;
 wal_buffers
-------------
 64kB

--
Greg Sabino Mullane [email-masked]
End Point Corporation
PGP Key: 0x14964AC8 200807241351
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8

---

From: "Joshua D. Drake" <[email-masked]>
Date: Thu, 24 Jul 2008 11:02:39 -0700

On Thu, 2008-07-24 at 17:54 +0000, Greg Sabino Mullane wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: RIPEMD160
> everywhere, and get rid of the confusing '8kB' unit in pg_settings? 

+1

We have helper functions like pg_size_pretty() to resolve the other
issues.

Joshua D. Drake

-- 
The PostgreSQL Company since 1997: http://www.commandprompt.com/ 
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate

---

From: Greg Smith <[email-masked]>
Date: Sat, 26 Jul 2008 17:47:05 -0400 (EDT)

> everywhere, and get rid of the confusing '8kB' unit in pg_settings?

There's already some changes needed in this area needed to execute the 
full GUC cleanup/wizard plan that's being worked on.  The pg_settings view 
really should show the value both as the user input it and as it's stored 
internally for cases like these, which lowers the confusion here a bit 
even without going so far as converting everything to bytes.

--
* Greg Smith [email-masked] http://www.gregsmith.com Baltimore, MD

---

From: Bruce Momjian <[email-masked]>
Date: Tue, 12 Aug 2008 13:48:41 -0400 (EDT)

> even without going so far as converting everything to bytes.

Is this a TODO?

-- 
  Bruce Momjian  <[email-masked]>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---

From: Greg Smith <[email-masked]>
Date: Tue, 12 Aug 2008 15:43:44 -0400 (EDT)

>> even without going so far as converting everything to bytes.

I don't think you need yet another TODO for every detail, the existing 
TODO "Add external tool to auto-tune some postgresql.conf parameters" has 
to squash a bunch of issues in this area.  This particular issue Greg 
raised will already be improved significantly if executing the larger 
project plan at http://wiki.postgresql.org/wiki/GUCS_Overhaul

This week Robert Treat and I have been doing a lot of work on "Problem #1" 
there, "Most people have no idea how to set [GUCs]" which I know some 
people wanted to see a more formal document for before mucking with any of 
the code.  I'll have something to announce there shortly.

---

From: Decibel! <[email-masked]>
Date: Fri, 22 Aug 2008 00:49:23 -0500

On Aug 12, 2008, at 2:43 PM, Greg Smith wrote:
> I don't think you need yet another TODO for every detail, the  
> existing TODO "Add external tool to auto-tune some postgresql.conf  
> parameters" has to squash a bunch of issues in this area.  This  
> particular issue Greg raised will already be improved significantly  
> if executing the larger project plan at http://wiki.postgresql.org/ 
> wiki/GUCS_Overhaul

Yeah, but OTOH it's not clear at all when we might see such a tool,  
while clarifying this stuff would help people immediately... I think  
a TODO would be good to make sure this doesn't fall through the cracks.
-- 
Decibel!, aka Jim C. Nasby, Database Architect  [email-masked]
Give your computer some brain candy! www.distributed.net Team #1828

---

From: Bruce Momjian <[email-masked]>
Date: Mon, 15 Dec 2008 18:23:02 -0500 (EST)

> an idea how to clarify things?

I have updated the table title to be clearer.

  + If your life is a hard drive, Christ can be your backup. +
Index: doc/src/sgml/runtime.sgml
===================================================================
RCS file: /cvsroot/pgsql/doc/src/sgml/runtime.sgml,v
retrieving revision 1.422
diff -c -c -r1.422 runtime.sgml
*** doc/src/sgml/runtime.sgml	20 Nov 2008 11:48:26 -0000	1.422
--- doc/src/sgml/runtime.sgml	15 Dec 2008 23:22:24 -0000
***************
*** 1087,1093 ****
       <thead>
        <row>
         <entry>Name</>
!        <entry>Approximate multiplier (bytes per increment) as of 8.3</>
        </row>
       </thead>
  
--- 1087,1093 ----
       <thead>
        <row>
         <entry>Name</>
!        <entry>Additional bytes per object, as of 8.3</>
        </row>
       </thead>
  
***************
*** 1119,1125 ****
  
        <row>
         <entry>Fixed space requirements</>
!        <entry>770 kB</entry>
        </row>
       </tbody>
      </tgroup>
--- 1119,1125 ----
  
        <row>
         <entry>Fixed space requirements</>
!        <entry>770 k</entry>
        </row>
       </tbody>
      </tgroup>

---

From: Bruce Momjian <[email-masked]>
Date: Mon, 15 Dec 2008 18:32:36 -0500 (EST)

I have added this TODO item:

	Rationalize the discrepancy between settings that use values in bytes
	and SHOW that returns the object count
	
        * http://archives.postgresql.org/pgsql-docs/2008-07/msg00007.php 

---------------------------------------------------------------------------

Greg Sabino Mullane wrote:
[ There is text before PGP section. ]
> -----BEGIN PGP SIGNATURE-----
> 
> iEYEAREDAAYFAkiIwYYACgkQvJuQZxSWSsiY5wCfU/tca+1JakWaMCDDRHEHk/Uj
> 1rcAoMi1FNGSpJhyXWde1psygq6v3MlS
> =gCPg
> -----END PGP SIGNATURE-----
> 
> 
> 
> -- 
> Sent via pgsql-docs mailing list ([email-masked])
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-docs

---

From: Alvaro Herrera <[email-masked]>
Date: Mon, 15 Dec 2008 20:43:37 -0300

> I have updated the table title to be clearer.

I don't find it any clearer ... I think the missing clue is that if you
specify shared_buffers values in MB, you must divide the value by block
size.

This change is wrong, why did you do it?

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

---

From: Bruce Momjian <[email-masked]>
Date: Mon, 15 Dec 2008 18:46:00 -0500 (EST)

> specify shared_buffers values in MB, you must divide the value by block

Well, the heading says "object" now so I thought it would suggest we are
talking about objects and not bytes.

> This change is wrong, why did you do it?

The heading says "bytes" so having the "B" was unnecessary and possibly
confusing.

---

From: Tom Lane <[email-masked]>
Date: Mon, 15 Dec 2008 19:35:38 -0500

> talking about objects and not bytes.

I'm with Alvaro: neither of those changes were improvements.

			regards, tom lane

---

From: Bruce Momjian <[email-masked]>
Date: Mon, 15 Dec 2008 22:13:21 -0500 (EST)

> I'm with Alvaro: neither of those changes were improvements.

OK, I never got the change applied because of Alvaro's objection so
there is nothing to revert.   Alvaro said he has an idea for improved
wording;  I do not.

---

From: Alvaro Herrera <[email-masked]>
Date: Tue, 16 Dec 2008 11:43:27 -0300

> there is nothing to revert.   Alvaro said he has an idea for improved

I think we should add a more explicit note, like in the attached patch.

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
Index: runtime.sgml
===================================================================
RCS file: /home/alvherre/Code/cvs/pgsql/doc/src/sgml/runtime.sgml,v
retrieving revision 1.422
diff -c -p -r1.422 runtime.sgml
*** runtime.sgml	20 Nov 2008 11:48:26 -0000	1.422
--- runtime.sgml	16 Dec 2008 14:40:42 -0000
*************** set semsys:seminfo_semmsl=32
*** 1124,1129 ****
--- 1124,1139 ----
       </tbody>
      </tgroup>
     </table>
+ 
+    <note>
+     <para>
+      The multipliers for <varname>shared_buffers</> and
+      <varname>wal_buffers</> should be the number of buffers, not the
+      amount in bytes.  To find out the number of shared or wal buffers, divide
+      the amount in bytes by <xref linkend="guc-block-size"> and
+      <xref linkend="guc-wal-block-size">, respectively.
+     </para>
+    </note>
    </sect2>

---

From: Alvaro Herrera <[email-masked]>
Date: Tue, 16 Dec 2008 16:33:14 -0300

> I think we should add a more explicit note, like in the attached patch.

Committed.  Bruce told me on IM he still wants to do more changes.

---

From: Bruce Momjian <[email-masked]>
Date: Tue, 16 Dec 2008 17:06:53 -0500 (EST)

> Committed.  Bruce told me on IM he still wants to do more changes.

OK, updated patch.  I added item descriptions and removed Alvaro's
paragraph;  I worked with Alvaro on this patch.

You can see the output in table 17-2:

	http://momjian.us/tmp/pgsql/kernel-resources.html

  + If your life is a hard drive, Christ can be your backup. +
Index: doc/src/sgml/runtime.sgml
===================================================================
RCS file: /cvsroot/pgsql/doc/src/sgml/runtime.sgml,v
retrieving revision 1.423
diff -c -c -r1.423 runtime.sgml
*** doc/src/sgml/runtime.sgml	16 Dec 2008 19:30:43 -0000	1.423
--- doc/src/sgml/runtime.sgml	16 Dec 2008 22:01:14 -0000
***************
*** 1087,1141 ****
       <thead>
        <row>
         <entry>Name</>
!        <entry>Approximate multiplier (bytes per increment) as of 8.3</>
        </row>
       </thead>
  
       <tbody>
        <row>
         <entry><xref linkend="guc-max-connections"></>
!        <entry>1800 + 270 * <xref linkend="guc-max-locks-per-transaction"></entry>
        </row>
  
        <row>
         <entry><xref linkend="guc-autovacuum-max-workers"></>
!        <entry>1800 + 270 * <xref linkend="guc-max-locks-per-transaction"></entry>
        </row>
  
        <row>
         <entry><xref linkend="guc-max-prepared-transactions"></>
!        <entry>770 + 270 * <xref linkend="guc-max-locks-per-transaction"></entry>
        </row>
  
        <row>
         <entry><xref linkend="guc-shared-buffers"></>
!        <entry>8400 (assuming 8 kB <symbol>BLCKSZ</>)</entry>
        </row>
  
        <row>
         <entry><xref linkend="guc-wal-buffers"></>
!        <entry>8200 (assuming 8 kB <symbol>XLOG_BLCKSZ</>)</entry>
        </row>
  
        <row>
  
!    <note>
!     <para>
!      The multipliers for <varname>shared_buffers</> and
!      <varname>wal_buffers</> should be the number of buffers, not the
!      amount in bytes.  To find out the number of shared or wal buffers, divide
!      the amount in bytes by <xref linkend="guc-block-size"> and
!      <xref linkend="guc-wal-block-size">, respectively.
!     </para>
!    </note>
!   </sect2>
! 
  
    <sect2>
     <title>Resource Limits</title>
--- 1087,1137 ----
       <thead>
        <row>
         <entry>Name</>
!        <entry>Shared memory requirements, as of 8.3</>
        </row>
       </thead>
  
       <tbody>
        <row>
         <entry><xref linkend="guc-max-connections"></>
!        <entry>1800 + 270 * <xref
!        linkend="guc-max-locks-per-transaction"> bytes per connection</entry>
        </row>
  
        <row>
         <entry><xref linkend="guc-autovacuum-max-workers"></>
!        <entry>1800 + 270 * <xref
!        linkend="guc-max-locks-per-transaction"> bytes per worker</entry>
        </row>
  
        <row>
         <entry><xref linkend="guc-max-prepared-transactions"></>
!        <entry>770 + 270 * <xref
!        linkend="guc-max-locks-per-transaction"> bytes per prepared transaction</entry>
        </row>
  
        <row>
         <entry><xref linkend="guc-shared-buffers"></>
!        <entry><xref linkend="guc-block-size"> + 208 bytes per shared buffer</entry>
        </row>
  
        <row>
         <entry><xref linkend="guc-wal-buffers"></>
!        <entry><xref linkend="guc-wal-block-size"> + 8 bytes per WAL buffer</entry>
        </row>
  
        <row>
         <entry>Fixed space requirements</>
!        <entry>770k bytes</entry>
        </row>
       </tbody>
      </tgroup>
     </table>
  
!    <para>
!     These shared memory allocations are reserved at database server
!     start and remain static.
!    </para>
  
    <sect2>
     <title>Resource Limits</title>

---

From: Tom Lane <[email-masked]>
Date: Tue, 16 Dec 2008 18:38:17 -0500

> paragraph;  I worked with Alvaro on this patch.

This still seems pretty misleading, as for example
  
> !        linkend="guc-max-locks-per-transaction"> bytes per connection</entry>

sounds like it might mean bytes per *active* connection, when of course
the correct way to figure it is by multiplying by max_connections.
If you're going to give a formula, why not just give a formula, eg

	(1800 + 270 * max_locks_per_transaction) * (max_connections + autovacuum_max_workers)

			regards, tom lane

---

From: Bruce Momjian <[email-masked]>
Date: Tue, 16 Dec 2008 20:33:36 -0500 (EST)

> 	(1800 + 270 * max_locks_per_transaction) * (max_connections + autovacuum_max_workers)

You mean like this:

--- doc/src/sgml/runtime.sgml	17 Dec 2008 01:30:21 -0000
  
       <tbody>
        <row>
!        <entry><xref linkend="guc-max-connections"></>
!        <entry>1800 + 270 * <xref linkend="guc-max-locks-per-transaction"></entry>
!       </row>
! 
!       <row>
!        <entry><xref linkend="guc-autovacuum-max-workers"></>
!        <entry>1800 + 270 * <xref linkend="guc-max-locks-per-transaction"></entry>
        </row>
  
        <row>
  
        <row>
  
        <row>
  
        <row>
  
!    <note>
!     <para>
  
    <sect2>
     <title>Resource Limits</title>
--- 1087,1132 ----
       <thead>
        <row>
         <entry>Name</>
!        <entry>Shared memory bytes required, as of 8.3</>
        </row>
       </thead>
  
       <tbody>
        <row>
!        <entry><xref linkend="guc-max-connections">, <xref linkend="guc-autovacuum-max-workers"></>
!        <entry>(1800 + 270 * <xref
!        linkend="guc-max-locks-per-transaction">) * (<xref
!        linkend="guc-max-connections"> + <xref linkend="guc-autovacuum-max-workers">)</entry>
        </row>
  
        <row>
         <entry><xref linkend="guc-max-prepared-transactions"></>
!        <entry>(770 + 270 * <xref
!        linkend="guc-max-locks-per-transaction">) * <xref linkend="guc-max-prepared-transactions"></entry>
        </row>
  
        <row>
         <entry><xref linkend="guc-shared-buffers"></>
!        <entry>(<xref linkend="guc-block-size"> + 208) * <xref linkend="guc-shared-buffers"></entry>
        </row>
  
        <row>
         <entry><xref linkend="guc-wal-buffers"></>
!        <entry>(<xref linkend="guc-wal-block-size"> + 8) * <xref linkend="guc-wal-buffers"></entry>
        </row>
  
        <row>
  
!    <para>
  
    <sect2>

---

From: Tom Lane <[email-masked]>
Date: Tue, 16 Dec 2008 22:31:15 -0500

> 	http://momjian.us/tmp/pgsql/kernel-resources.html

Yeah, more or less.  A couple thoughts now that I see it worked out:

* Combining the entries for max_connections and autovacuum_max_workers
is probably just making it look more complicated than it needs to.
How about two rows that just happen to have similar formulas, viz

max_connections		(1800 + 270 * max_locks_per_transaction) * max_connections
autovacuum_max_workers	(1800 + 270 * max_locks_per_transaction) * autovacuum_max_workers

* The right-hand column header should be something like "Approximate
shared memory bytes..." to avoid the impression that these formulas
are meant to be exact.

* If we do it like this then the left-hand column is really redundant,
not to say wrong because the right-hand formulas depend on more than
the single variable mentioned.  How about something like

	Table 17-2	PostgreSQL shared memory usage

Purpose				Approximate number of bytes required (as of 8.3)

Per-connection state		(1800 + 270 * max_locks_per_transaction) * max_connections
Autovacuum worker state		(1800 + 270 * max_locks_per_transaction) * autovacuum_max_workers
Prepared transaction state	...
Shared disk buffers		...
WAL buffers			...
Fixed space requirements	770kB

			regards, tom lane

---

From: Bruce Momjian <[email-masked]>
Date: Wed, 17 Dec 2008 08:41:40 -0500 (EST)

> Fixed space requirements	770kB

OK, I updated it again:

I did change your left column wording because it could be interpreted as
something that changes during server execution, e.g. connections.

---

From: Tom Lane <[email-masked]>
Date: Wed, 17 Dec 2008 08:53:44 -0500

> something that changes during server execution, e.g. connections.

[ shrug... ]  I don't find what you did to be an improvement over what
I suggested, but I don't have time to argue about it.

			regards, tom lane

---

From: Bruce Momjian <[email-masked]>
Date: Wed, 17 Dec 2008 09:11:20 -0500 (EST)

> I suggested, but I don't have time to argue about it.

I decided I didn't like what I did either;  updated version with new
headings and shorter descriptions:

---

From: Alvaro Herrera <[email-masked]>
Date: Wed, 17 Dec 2008 12:20:38 -0300

> 	http://momjian.us/tmp/pgsql/kernel-resources.html

This version seems good to me, except please put back the B to the end
of "770 k".

---

From: Bruce Momjian <[email-masked]>
Date: Thu, 18 Dec 2008 12:07:20 -0500 (EST)

> This version seems good to me, except please put back the B to the end

Patch applied with "B" re-added, though I would like to mention again
that it is inconsistent because we don't mention bytes in any other row
in that column.

  + If your life is a hard drive, Christ can be your backup. +
Index: runtime.sgml
===================================================================
RCS file: /cvsroot/pgsql/doc/src/sgml/runtime.sgml,v
retrieving revision 1.423
retrieving revision 1.424
diff -c -c -r1.423 -r1.424
*** runtime.sgml	16 Dec 2008 19:30:43 -0000	1.423
--- runtime.sgml	18 Dec 2008 17:03:09 -0000	1.424
***************
*** 1,4 ****
! <!-- $PostgreSQL: pgsql/doc/src/sgml/runtime.sgml,v 1.423 2008/12/16 19:30:43 alvherre Exp $ -->
  
  <chapter Id="runtime">
   <title>Operating System Environment</title>
--- 1,4 ----
! <!-- $PostgreSQL: pgsql/doc/src/sgml/runtime.sgml,v 1.424 2008/12/18 17:03:09 momjian Exp $ -->
  
  <chapter Id="runtime">
   <title>Operating System Environment</title>
***************
*** 1080,1120 ****

     <table id="shared-memory-parameters">
!     <title>Configuration parameters affecting
!     <productname>PostgreSQL</productname>'s shared memory usage</>
  
      <tgroup cols="2">
       <thead>
        <row>
!        <entry>Name</>
  
       <tbody>
        <row>
  
        <row>
  
        <row>
!        <entry><xref linkend="guc-max-prepared-transactions"></>
!        <entry>770 + 270 * <xref linkend="guc-max-locks-per-transaction"></entry>
        </row>
  
        <row>
!        <entry><xref linkend="guc-shared-buffers"></>
!        <entry>8400 (assuming 8 kB <symbol>BLCKSZ</>)</entry>
        </row>
  
        <row>
!        <entry><xref linkend="guc-wal-buffers"></>
!        <entry>8200 (assuming 8 kB <symbol>XLOG_BLCKSZ</>)</entry>
        </row>
  
        <row>
--- 1080,1124 ----

     <table id="shared-memory-parameters">
!     <title><productname>PostgreSQL</productname> shared memory usage</>
  
      <tgroup cols="2">
       <thead>
        <row>
!        <entry>Usage</>
!        <entry>Approximate shared memory bytes required (as of 8.3)</>
        </row>
       </thead>
  
       <tbody>
        <row>
!        <entry>Connections</>
!        <entry>(1800 + 270 * <xref
!        linkend="guc-max-locks-per-transaction">) * <xref
!        linkend="guc-max-connections"></entry>
        </row>
  
        <row>
!        <entry>Autovacuum workers</>
!        <entry>(1800 + 270 * <xref
!        linkend="guc-max-locks-per-transaction">) * <xref
!        linkend="guc-autovacuum-max-workers"></entry>
        </row>
  
        <row>
!        <entry>Prepared transactions</>
!        <entry>(770 + 270 * <xref
!        linkend="guc-max-locks-per-transaction">) * <xref linkend="guc-max-prepared-transactions"></entry>
        </row>
  
        <row>
!        <entry>Shared disk buffers</>
!        <entry>(<xref linkend="guc-block-size"> + 208) * <xref linkend="guc-shared-buffers"></entry>
        </row>
  
        <row>
!        <entry>WAL buffers</>
  
        <row>
***************
*** 1125,1142 ****
      </tgroup>
     </table>
  
-    <note>
-     <para>
-      The multipliers for <varname>shared_buffers</> and
-      <varname>wal_buffers</> should be the number of buffers, not the
-      amount in bytes.  To find out the number of shared or wal buffers, divide
-      the amount in bytes by <xref linkend="guc-block-size"> and
-      <xref linkend="guc-wal-block-size">, respectively.
-     </para>
-    </note>
    </sect2>
  
- 
    <sect2>
  
--- 1129,1136 ----

---

From: Alvaro Herrera <[email-masked]>
Date: Thu, 18 Dec 2008 14:10:03 -0300

> that it is inconsistent because we don't mention bytes in any other row

The heading already says "bytes".