diff --git a/doc/README.NT b/doc/FAQ_NT similarity index 100% rename from doc/README.NT rename to doc/FAQ_NT diff --git a/doc/README.BSDI b/doc/README.BSDI deleted file mode 100644 index 0392f26ee7dd2dc0f633a4e5f6ccfe8f9327ecec..0000000000000000000000000000000000000000 --- a/doc/README.BSDI +++ /dev/null @@ -1,31 +0,0 @@ -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. - -Bruce Momjian (pgman@candle.pha.pa.us) - ---------------------------------------------------------------------------- - -First, 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. - -Second, 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. - -This should clearly be easier to do on BSDI. I will add a BSDI FAQ for -PostgreSQL to cover this. One downside is that shared memory is not -pageable. It is locked in RAM. diff --git a/doc/TODO.detail/replication b/doc/TODO.detail/replication index d18f7db52d0a6edb016c83a523fa276fc98824cb..077a90bf09f3f6dc59cb83c2cbc9555f426db9db 100644 --- a/doc/TODO.detail/replication +++ b/doc/TODO.detail/replication @@ -43,7 +43,7 @@ From owner-pgsql-hackers@hub.org Fri Dec 24 10:01:18 1999 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 LAA11295 for <pgman@candle.pha.pa.us>; Fri, 24 Dec 1999 11:01:17 -0500 (EST) -Received: from hub.org (hub.org [216.126.84.1]) by renoir.op.net (o1/$Revision: 1.1 $) with ESMTP id KAA20310 for <pgman@candle.pha.pa.us>; Fri, 24 Dec 1999 10:39:18 -0500 (EST) +Received: from hub.org (hub.org [216.126.84.1]) by renoir.op.net (o1/$Revision: 1.2 $) with ESMTP id KAA20310 for <pgman@candle.pha.pa.us>; Fri, 24 Dec 1999 10:39:18 -0500 (EST) Received: from localhost (majordom@localhost) by hub.org (8.9.3/8.9.3) with SMTP id KAA61760; Fri, 24 Dec 1999 10:31:13 -0500 (EST) @@ -129,7 +129,7 @@ From owner-pgsql-hackers@hub.org Fri Dec 24 18:31:03 1999 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 TAA26244 for <pgman@candle.pha.pa.us>; Fri, 24 Dec 1999 19:31:02 -0500 (EST) -Received: from hub.org (hub.org [216.126.84.1]) by renoir.op.net (o1/$Revision: 1.1 $) with ESMTP id TAA12730 for <pgman@candle.pha.pa.us>; Fri, 24 Dec 1999 19:30:05 -0500 (EST) +Received: from hub.org (hub.org [216.126.84.1]) by renoir.op.net (o1/$Revision: 1.2 $) with ESMTP id TAA12730 for <pgman@candle.pha.pa.us>; Fri, 24 Dec 1999 19:30:05 -0500 (EST) Received: from localhost (majordom@localhost) by hub.org (8.9.3/8.9.3) with SMTP id TAA57851; Fri, 24 Dec 1999 19:23:31 -0500 (EST) @@ -212,7 +212,7 @@ From owner-pgsql-hackers@hub.org Fri Dec 24 21:31:10 1999 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 WAA02578 for <pgman@candle.pha.pa.us>; Fri, 24 Dec 1999 22:31:09 -0500 (EST) -Received: from hub.org (hub.org [216.126.84.1]) by renoir.op.net (o1/$Revision: 1.1 $) with ESMTP id WAA16641 for <pgman@candle.pha.pa.us>; Fri, 24 Dec 1999 22:18:56 -0500 (EST) +Received: from hub.org (hub.org [216.126.84.1]) by renoir.op.net (o1/$Revision: 1.2 $) with ESMTP id WAA16641 for <pgman@candle.pha.pa.us>; Fri, 24 Dec 1999 22:18:56 -0500 (EST) Received: from localhost (majordom@localhost) by hub.org (8.9.3/8.9.3) with SMTP id WAA89135; Fri, 24 Dec 1999 22:11:12 -0500 (EST) @@ -486,7 +486,7 @@ From owner-pgsql-hackers@hub.org Sun Dec 26 08:31:09 1999 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 JAA17976 for <pgman@candle.pha.pa.us>; Sun, 26 Dec 1999 09:31:07 -0500 (EST) -Received: from hub.org (hub.org [216.126.84.1]) by renoir.op.net (o1/$Revision: 1.1 $) with ESMTP id JAA23337 for <pgman@candle.pha.pa.us>; Sun, 26 Dec 1999 09:28:36 -0500 (EST) +Received: from hub.org (hub.org [216.126.84.1]) by renoir.op.net (o1/$Revision: 1.2 $) with ESMTP id JAA23337 for <pgman@candle.pha.pa.us>; Sun, 26 Dec 1999 09:28:36 -0500 (EST) Received: from localhost (majordom@localhost) by hub.org (8.9.3/8.9.3) with SMTP id JAA90738; Sun, 26 Dec 1999 09:21:58 -0500 (EST) @@ -905,3 +905,100 @@ Sys Admin ************ +From owner-pgsql-hackers@hub.org Thu Dec 30 08:01:09 1999 +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 JAA10317 + for <pgman@candle.pha.pa.us>; Thu, 30 Dec 1999 09:01:08 -0500 (EST) +Received: from hub.org (hub.org [216.126.84.1]) by renoir.op.net (o1/$Revision: 1.2 $) with ESMTP id IAA02365 for <pgman@candle.pha.pa.us>; Thu, 30 Dec 1999 08:37:10 -0500 (EST) +Received: from localhost (majordom@localhost) + by hub.org (8.9.3/8.9.3) with SMTP id IAA87902; + Thu, 30 Dec 1999 08:34:22 -0500 (EST) + (envelope-from owner-pgsql-hackers) +Received: by hub.org (bulk_mailer v1.5); Thu, 30 Dec 1999 08:32:24 -0500 +Received: (from majordom@localhost) + by hub.org (8.9.3/8.9.3) id IAA85771 + for pgsql-hackers-outgoing; Thu, 30 Dec 1999 08:31:27 -0500 (EST) + (envelope-from owner-pgsql-hackers@postgreSQL.org) +Received: from sandman.acadiau.ca (dcurrie@sandman.acadiau.ca [131.162.129.111]) + by hub.org (8.9.3/8.9.3) with ESMTP id IAA85234 + for <pgsql-hackers@postgresql.org>; Thu, 30 Dec 1999 08:31:10 -0500 (EST) + (envelope-from dcurrie@sandman.acadiau.ca) +Received: (from dcurrie@localhost) + by sandman.acadiau.ca (8.8.8/8.8.8/Debian/GNU) id GAA18698; + Thu, 30 Dec 1999 06:30:58 -0400 +From: Duane Currie <dcurrie@sandman.acadiau.ca> +Message-Id: <199912301030.GAA18698@sandman.acadiau.ca> +Subject: Re: [HACKERS] database replication +In-Reply-To: <OFD38C9424.B391F434-ON85256851.0054F41A@black-oak.COM> from "DWalker@black-oak.com" at "Dec 24, 99 10:27:59 am" +To: DWalker@black-oak.com +Date: Thu, 30 Dec 1999 10:30:58 +0000 (AST) +Cc: pgsql-hackers@postgresql.org +X-Mailer: ELM [version 2.4ME+ PL39 (25)] +MIME-Version: 1.0 +Content-Type: text/plain; charset=US-ASCII +Content-Transfer-Encoding: 7bit +Sender: owner-pgsql-hackers@postgresql.org +Status: OR + +Hi Guys, + +Now for one of my REALLY rare posts. +Having done a little bit of distributed data systems, I figured I'd +pitch in a couple cents worth. + +> 2) The replication system will need to add at least one field to each +> table in each database that needs to be re plicated. This +> field will be a date/time stamp which identifies the " last +> update" of the record. This field will be called PGR_TIME +> for la ck of a better name. Because this field will be used +> from within programs and triggers it can be longer so as to not +> mistake it for a user field. + +I just started reading this thread, but I figured I'd throw in a couple +suggestions for distributed data control (a few idioms I've had to +deal with b4): + - Never use time (not reliable from system to system). Use + a version number of some sort that can stay consistent across + all replicas + + This way, if a system's time is or goes out of wack, it doesn't + cause your database to disintegrate, and it's easier to track + conflicts (see below. If using time, the algorithm gets + nightmarish) + + - On an insert, set to version 1 + + - On an update, version++ + + - On a delete, mark deleted, and add a delete stub somewhere for the + replicator process to deal with in sync'ing the databases. + + - If two records have the same version but different data, there's + a conflict. A few choices: + 1. Pick one as the correct one (yuck!! invisible data loss) + 2. Store both copies, pick one as current, and alert + database owner of the conflict, so they can deal with + it "manually." + 3. If possible, some conflicts can be merged. If a disjoint + set of fields were changed in each instance, these changes + may both be applied and the record merged. (Problem: + takes a lot more space. Requires a version number for + every field, or persistent storage of some old records. + However, this might help the "which fields changed" issue + you were talking about in #6) + + - A unique id across all systems should exist (or something that + effectively simulates a unique id. Maybe a composition of the + originating oid (from the insert) and the originating database + (oid of the database's record?) might do it. Store this as + an extra field in every record. + + (Two extra fieldss so far: 'unique id' and 'version') + +I do like your approach: triggers and a separate process. (Maintainable!! :) + +Anyway, just figured I'd throw in a few suggestions, +Duane + +************ +