Re: [HACKERS] FAQ: Current state of replication ?

2001-03-21 Thread Christopher Masto

On Mon, Mar 19, 2001 at 11:00:20AM -, Peter Galbavy wrote:
 1. One "writer", many "reader" PostgreSQL servers. We will want to write
 provisioning / configuration information centrally and can tolerate a
 "writer" failuer for a time.
 2. Consitency at the transaction level. All changes to the "writer" server
 will be wrapped in transactions, and there will be foreign key consistency
 checking in many tables.
 3. Delays from "writer" through to consistent state on "readers" can be
 tolerated to within a few minutes or even more. All read-servers must be in
 the same state when answering requests.
 
 Our objective is to acheive performance and some fault tolerance as the data
 is going to be used for near-real time configuration of various other
 backend systems in an almost traditional 'net environment.

Your application sounds like a perfect fit for LDAP.

In other words, keep your database in Postgres, but export views of it
through for clients to query through LDAP.  Rely on LDAP replication,
since it has the model you need and works today.
-- 
Christopher Masto Senior Network Monkey  NetMonger Communications
[EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net

Free yourself, free your machine, free the daemon -- http://www.freebsd.org/

---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://www.postgresql.org/search.mpl



Re: [HACKERS] FAQ: Current state of replication ?

2001-03-20 Thread Joe Conway

 1. One "writer", many "reader" PostgreSQL servers. We will want to write
 provisioning / configuration information centrally and can tolerate a
 "writer" failuer for a time.
 2. Consitency at the transaction level. All changes to the "writer" server
 will be wrapped in transactions, and there will be foreign key consistency
 checking in many tables.
 3. Delays from "writer" through to consistent state on "readers" can be
 tolerated to within a few minutes or even more. All read-servers must be
in
 the same state when answering requests.

 Our objective is to acheive performance and some fault tolerance as the
data
 is going to be used for near-real time configuration of various other
 backend systems in an almost traditional 'net environment.

 As we are coding various other stuff for this project over the next few
 months, any help we can be in developing for this part of PostgreSQL, just
 let me know. While knowing very little about PostgreSQL internals, we
learn
 quick.

Peter,

I've been mostly a lurker here (at least on the hackers list) for a couple
of years, but I thought I would "de-lurk" for long enough to reply to your
question ;)

Attached is the source for a replication solution I recently wrote for a
project I'm working on. I think it meets your criteria. I was considering
sending it to the list as a possible contrib after 7.1 was released (if
anyone is interested, and the code is worthy), but since you asked, here it
is. A few disclaimers are in order. First, I am *not* an experienced C
programmer. The code works in the limited testing I've done so far but needs
to be reviewed and scrubbed by someone with more experience. Second, I have
not yet used this in production, so use at your own risk. Third, I have only
tested it under Red Hat 6.2 and 7.0. Finally, it will only work with =
PostgreSQL 7.1 beta3.

Basic installation instructions:
  copy pg_lnk.tgz to contrib under the PostgreSQL source tree
  tar -xzvf pg_lnk.tgz
  cd pg_lnk
  ./install.sh

I'll be happy to answer any questions to help you get it installed and
working. I would appreciate any feedback, improvements, general guidance if
you decide to use it.

Thanks,

Joe

lurking once again . . .


 pg_lnk.tgz


---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html