Re: Peer to peer replication of Postgresql databases - Mailing list pgsql-hackers

From Anuradha Ratnaweera
Subject Re: Peer to peer replication of Postgresql databases
Date
Msg-id 20021014060530.GA23353@lklug.pdn.ac.lk
Whole thread Raw
In response to Re: Peer to peer replication of Postgresql databases  (Neil Conway <neilc@samurai.com>)
List pgsql-hackers
On Fri, Oct 11, 2002 at 12:07:00PM -0400, Neil Conway wrote:
> [ pgsql-patches removed from Cc: list ]
> 
> Anuradha Ratnaweera <anuradha@lklug.pdn.ac.lk> writes:
> > I am trying to add some replication features to postgres (yes, I
> > have already looked at ongoing work), in a peer to peer manner.
> 
> Did you look at the research behind Postgres-R, and the pgreplication
> stuff?

Am looking at the research papers related to it now.

> > - When a frontend process sends a read query, each backend process
> >   does that from its own data area.
> 
> Surely that's not correct -- a SELECT can be handled by *any one*
> node, not each and every one, right?

Yes.  Sorry about my careless wording.  Unless anything is kind of
locked, each node has a copy of the database, so each one can handle
SELECTs individually.

The actual situation will be far from this simple, because there will be
database writes going on and generating consistent SELECTs would need
careful handling of concurency issues.

> > - There are two types of write queries.  Postmasters use seperate
> >   communication channels for each.  One is the sequencial channel which
> >   carries writes whose order is important, and the non-sequencial
> >   channel carries write queries whose order is not important.
> 
> How do you distinguish between these?

Nope.  We assume that all the communication should go through the
sequencial channel unless indicated by the client.  In that case, we
will have to find a way to indicate this from the client's side.  This
doesn't sound very elegant, may be we can figure out a better way.
Anuradha

-- 

Debian GNU/Linux (kernel 2.4.18-xfs-1.1)

"Being against torture ought to be sort of a bipartisan thing."
-- Karl Lehenbauer



pgsql-hackers by date:

Previous
From: Joe Conway
Date:
Subject: Re: droped out precise time calculations in src/interfaces/libpq/fe-connect.c
Next
From: Denis A Ustimenko
Date:
Subject: Re: droped out precise time calculations in src/interfaces/libpq/fe-connect.c