Update faq's.
This commit is contained in:
Bruce Momjian
parent
bff5dce993
commit
acad203c31
@ -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.
|
||||
@ -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
|
||||
|
||||
************
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user