Reverse PG_BINARY defines

doc/FAQ_BSDI

+This outlines how to increase the number of shared memory buffers
+supported by BSD/OS.  By default, only 4MB of shared memory is supported
+by BSDI.
+
+Keep in mind that shared memory is not pageable.  It is locked in RAM.
+
+Bruce Momjian (pgman@candle.pha.pa.us)
+
+---------------------------------------------------------------------------
+
+Increase SHMMAXPGS by 1024 for every additional 4MB of shared
+memory:
+
+/sys/sys/shm.h:69:#define       SHMMAXPGS       1024    /* max hardware pages...
+
+The default setting of 1024 is for a maximum of 4MB of shared memory.
+
+For those running 4.1 or later, just recompile the kernel and reboot. 
+For those running earlier releases, there are more steps outlined below.
+
+---------------------------------------------------------------------------
+
+Use bpatch to find the sysptsize value for the current kernel. 
+This is computed dynamically at bootup.
+
+	$ bpatch -r sysptsize
+	0x9 = 9
+
+Next, change SYSPTSIZE to a hard-coded value.  Use the bpatch value,
+plus add 1 for every additional 4MB of shared memory you desire.
+
+/sys/i386/i386/i386_param.c:28:#define  SYSPTSIZE 0        /* dynamically...
+
+sysptsize can not be changed by sysctl on the fly.

doc/TODO.detail/vacuum

@@ -1403,7 +1403,7 @@ From owner-pgsql-hackers@hub.org Sat Jan 22 02:31:03 2000
 Received: from renoir.op.net (root@renoir.op.net [207.29.195.4])
 	by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id DAA06743
 	for <pgman@candle.pha.pa.us>; Sat, 22 Jan 2000 03:31:02 -0500 (EST)
-Received: from hub.org (hub.org [216.126.84.1]) by renoir.op.net (o1/$Revision: 1.2 $) with ESMTP id DAA07529 for <pgman@candle.pha.pa.us>; Sat, 22 Jan 2000 03:25:13 -0500 (EST)
+Received: from hub.org (hub.org [216.126.84.1]) by renoir.op.net (o1/$Revision: 1.3 $) with ESMTP id DAA07529 for <pgman@candle.pha.pa.us>; Sat, 22 Jan 2000 03:25:13 -0500 (EST)
 Received: from localhost (majordom@localhost)
 	by hub.org (8.9.3/8.9.3) with SMTP id DAA31900;
 	Sat, 22 Jan 2000 03:19:53 -0500 (EST)
@@ -1475,7 +1475,7 @@ From tgl@sss.pgh.pa.us Sat Jan 22 10:31:02 2000
 Received: from renoir.op.net (root@renoir.op.net [207.29.195.4])
 	by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id LAA20882
 	for <pgman@candle.pha.pa.us>; Sat, 22 Jan 2000 11:31:00 -0500 (EST)
-Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2]) by renoir.op.net (o1/$Revision: 1.2 $) with ESMTP id LAA26612 for <pgman@candle.pha.pa.us>; Sat, 22 Jan 2000 11:12:44 -0500 (EST)
+Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2]) by renoir.op.net (o1/$Revision: 1.3 $) with ESMTP id LAA26612 for <pgman@candle.pha.pa.us>; Sat, 22 Jan 2000 11:12:44 -0500 (EST)
 Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
 	by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id LAA20569;
 	Sat, 22 Jan 2000 11:11:26 -0500 (EST)
@@ -1499,3 +1499,43 @@ Or equivalently, vacuum after updating all the rows.
 
 			regards, tom lane
 
+From tgl@sss.pgh.pa.us Thu Jan 20 23:51:49 2000
+Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
+	by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id AAA13919
+	for <pgman@candle.pha.pa.us>; Fri, 21 Jan 2000 00:51:47 -0500 (EST)
+Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
+	by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id AAA03644;
+	Fri, 21 Jan 2000 00:51:51 -0500 (EST)
+To: Bruce Momjian <pgman@candle.pha.pa.us>
+cc: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
+Subject: Re: vacuum timings 
+In-reply-to: <200001210543.AAA13592@candle.pha.pa.us> 
+References: <200001210543.AAA13592@candle.pha.pa.us>
+Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
+	message dated "Fri, 21 Jan 2000 00:43:49 -0500"
+Date: Fri, 21 Jan 2000 00:51:51 -0500
+Message-ID: <3641.948433911@sss.pgh.pa.us>
+From: Tom Lane <tgl@sss.pgh.pa.us>
+Status: ORr
+
+Bruce Momjian <pgman@candle.pha.pa.us> writes:
+> I loaded 10,000,000 rows into CREATE TABLE test (x INTEGER);  Table is
+> 400MB and index is 160MB.
+
+> With index on the single in4 column, I got:
+> 	 78 seconds for a vacuum
+> 	121 seconds for vacuum after deleting a single row
+> 	662 seconds for vacuum after deleting the entire table
+
+> With no index, I got:
+> 	 43 seconds for a vacuum
+> 	 43 seconds for vacuum after deleting a single row
+> 	 43 seconds for vacuum after deleting the entire table
+
+> I find this quite interesting.
+
+How long does it take to create the index on your setup --- ie,
+if vacuum did a drop/create index, would it be competitive?
+
+			regards, tom lane
+

src/include/c.h

@@ -8,7 +8,7 @@
  * Portions Copyright (c) 1996-2000, PostgreSQL, Inc
  * Portions Copyright (c) 1994, Regents of the University of California
  *
- * $Id: c.h,v 1.71 2000/06/02 15:57:40 momjian Exp $
+ * $Id: c.h,v 1.72 2000/06/02 16:33:17 momjian Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -896,7 +896,7 @@ extern char *vararg_format(const char *fmt,...);
  * ----------------------------------------------------------------
  */
 
-#ifndef __CYGWIN32__
+#ifdef __CYGWIN32__
 #define	PG_BINARY	0
 #define	PG_BINARY_R	"rb"
 #define	PG_BINARY_W	"wb"