postgres/contrib/rserv
Bruce Momjian b0f5086e41 oid is needed, it is added at the end of the struct (after the null
bitmap, if present).

Per Tom Lane's suggestion the information whether a tuple has an oid
or not is carried in the tuple descriptor.  For debugging reasons
tdhasoid is of type char, not bool.  There are predefined values for
WITHOID, WITHOUTOID and UNDEFOID.

This patch has been generated against a cvs snapshot from last week
and I don't expect it to apply cleanly to current sources.  While I
post it here for public review, I'm working on a new version against a
current snapshot.  (There's been heavy activity recently; hope to
catch up some day ...)

This is a long patch;  if it is too hard to swallow, I can provide it
in smaller pieces:

Part 1:  Accessor macros
Part 2:  tdhasoid in TupDesc
Part 3:  Regression test
Part 4:  Parameter withoid to heap_addheader
Part 5:  Eliminate t_oid from HeapTupleHeader

Part 2 is the most hairy part because of changes in the executor and
even in the parser;  the other parts are straightforward.

Up to part 4 the patched postmaster stays binary compatible to
databases created with an unpatched version.  Part 5 is small (100
lines) and finally breaks compatibility.

Manfred Koizar
2002-07-20 05:16:59 +00:00
..
ApplySnapshot.in This simple patch fixes broken Makefile, broken ApplySnapshot and 2002-03-06 20:41:36 +00:00
CleanLog.in This simple patch fixes broken Makefile, broken ApplySnapshot and 2002-03-06 20:41:36 +00:00
GetSyncID.in This simple patch fixes broken Makefile, broken ApplySnapshot and 2002-03-06 20:41:36 +00:00
InitRservTest.in rserv replication toolkit from Vadim Mikheev. 2000-12-20 17:22:35 +00:00
Makefile Back out this for Peter: 2002-03-11 04:39:14 +00:00
master.sql.in Install dynamically loadable modules into a private subdirectory 2001-09-16 16:11:11 +00:00
MasterAddTable.in rserv replication toolkit from Vadim Mikheev. 2000-12-20 17:22:35 +00:00
MasterInit.in Install dynamically loadable modules into a private subdirectory 2001-09-16 16:11:11 +00:00
MasterSync.in This simple patch fixes broken Makefile, broken ApplySnapshot and 2002-03-06 20:41:36 +00:00
PrepareSnapshot.in This simple patch fixes broken Makefile, broken ApplySnapshot and 2002-03-06 20:41:36 +00:00
README.rserv Rename undocumented utility SyncSyncID to MasterSync. 2000-12-21 15:26:04 +00:00
regress.sh Rename undocumented utility SyncSyncID to MasterSync. 2000-12-21 15:28:05 +00:00
Replicate.in This simple patch fixes broken Makefile, broken ApplySnapshot and 2002-03-06 20:41:36 +00:00
rserv.c oid is needed, it is added at the end of the struct (after the null 2002-07-20 05:16:59 +00:00
RServ.pm rserv replication toolkit from Vadim Mikheev. 2000-12-20 17:22:35 +00:00
RservTest.in rserv replication toolkit from Vadim Mikheev. 2000-12-20 17:22:35 +00:00
slave.sql.in rserv replication toolkit from Vadim Mikheev. 2000-12-20 17:22:35 +00:00
SlaveAddTable.in rserv replication toolkit from Vadim Mikheev. 2000-12-20 17:22:35 +00:00
SlaveInit.in Rename undocumented utility SyncSyncID to MasterSync. 2000-12-21 15:26:04 +00:00

erServer demonstration implementation
(c) 2000, Vadim Mikheev and Thomas Lockhart, PostgreSQL Inc.

Version 0.1:
  Replicates a master database to a single slave database.
  Tested under Linux (Mandrake 7.2).

Requirements:

- PostgreSQL >= 7.0.X
  A separate Makefile is required for PostgreSQL 7.0.x and earlier
- Perl5 and the PostgreSQL perl interface
- TCL and the PostgreSQL tcl interface (for demo only)


How to compile:

- make all
- make install

Scripts and libraries are installed in places which are consistant
with the way other contrib/ code is installed; underneath the core
items in a contrib/ directory.


The toolset:

MasterInit dbname
  sets up structures and user-defined functions for a master
  database. 

SlaveInit dbname
  sets up structures for a slave database. Does not include triggers,
  but only bookkeeping tables. 

MasterAddTable dbname table column
  sets up triggers for the specified table and column. Note that this
  column must be updated for replication to occur. 

SlaveAddTable dbname table column
  sets up bookkeeping for the specified table and column.

Replicate masterdb slavedb
  actually replicate changes from a master to single slave. Note that
  this must be repeated to replicate to multiple slaves, but the
  bookkeeping for each slave is handled separately so each can be
  updated at different times and with different sets of changes.

GetSyncID [--noverbose] slavedb
  returns the last syncid the specified slave has seen. May be used
  in conjunction with SyncSyncID and CleanLog using the --noverbose
  option.

MasterSync masterdb syncid
  registers a syncid with the specified master database. Used to
  propagate replication success back to the master database.

CleanLog masterdb syncid
  removes obsolete entries in the master database replication log
  table up to the specified replication sequence number.

Other utilities:

PrepareSnapshot
  build a file of replication information from the specified masterdb.

ApplySnapshot
  use a file of replication information to apply to the specified
  slavedb. 


How to run a demo:

Run the InitRservTest script. It will create two local databases
'master' & 'slave' with table 'test' in them. It accepts the following
arguments:
  --help
    Print a usage message and quit.
  --user name
    Access the database with another username.
  --host name
    Access a remote database. Note that the shared library *must* be
    visible in the same path as installed on the build machine.
  masterdb
  slavedb
    Names of test databases. Defaults to 'master' and 'slave',
	respectively.

Once the test databases are set up, simply updating the master table
is sufficient to log a replication event. You can update the table
test then run "Replicate master slave", or you can use the demo
program RservTest.

Run the tcl/tk GUI demo program, RservTest. It has a single window,
which has four buttons and three data entry boxes.

  --------------------------------------------------
 |   PostgreSQL Asynchronous Replication            |
 |        Master          Slave                     |
 |      < master    >   < slave      >              |
 |                                                  |
 |  [ Update    ]   <                         >     |
 |  [ Replicate ]                                   |
 |  [ Show      ]   ____________                    |
 |                                                  |
 |            [ Quit ]                              |
 |                                                  |
  --------------------------------------------------

The demo has the following behaviors:

If you enter a string into the data entry field to the right of
[Update], then that string will be used to either update the master
database or to query the slave database.

If you click [Update], then the string in the data entry box will be
entered into the master database.

If you click [Replicate], then all changes since the last replication
will be propagated to the slave database.

If you click [Show], then the slave database will be queried to find
the string in the data entry box to the right of the [Update]
button. If the string does not (yet) exist in the slave database, then
"n/a" will appear to the right of the [Show] button. If the string
does exist in the slave database, then it will be printed to the right
of the [Show] button.


Todo:
1. Support for multiple slave servers.
2. Explicit support for master/slave failover.
3. More docs.