Re: Big 7.4 items

Joe Conway wrote:
> Bruce Momjian wrote:
> > Win32 Port:
> > 
> >     Katie Ward and Jan are working on contributing their Win32
> >     port for 7.4.  They plan to have a patch available by the end of
> >     December.
> 
> I have .Net Studio available to me, so if you need help in merging or testing 
> or whatever, let me know.

OK, Jan, let him know how he can help.

> > Point-In-Time Recovery (PITR)
> > 
> >     J. R. Nield did a PITR patch late in 7.3 development, and Patrick
> >     MacDonald from Red Hat is working on merging it into CVS and
> >     adding any missing pieces.  Patrick, do you have an ETA on that?
> 
> As Hannu asked (and related to your question below), is there any thought of 
> extending this to allow simple log based replication? In many important 
> scenarios that would be more than adequate, and simpler to set up.

Yes, see previous email.

> I'd question if we would want the one-and-only builtin replication method to 
> be dependent on an external communication library (Spread). I would like to 
> see Postgres-R merged, but I'd also like to see a simple log-based option.

OK, let me reiterate I think we will have two replication solutions in
the end --- on Postgres-R for multi-master/synchronous, and PITR for
master/slave asynchronous replication.

Let me address the Spread issue and two-phase commit.  (Spread is an
open source piece of software used by Postgres-R.)

In two-phase commit, when one node is about to commit, it gets a lock
from all the other nodes, does its commit, then releases the lock.  (Of
course, this is simplified.)  It is called two-phase because it says to
all the other nodes "I am about to do something, is that OK?", then when
gets all OK's, it does the commit and says "I did the commit".

Postgres-R uses a different mechanism.  This method is shown on page 22
and 24 and following of:
ftp://gborg.postgresql.org/pub/pgreplication/stable/PostgreSQLReplication.pdf.gz

The basic difference is that Spread groups all the write sets into a
queue who's ordering is the same on all the nodes.  Instead of asking
for approval for a commit, a node puts its commit in the Spread queue,
and then waits for its own commit to come back in the queue, meaning all
the other nodes saw its commit too.

The only tricky part is that while reading the other node's write sets
before its own arrives, it has to check to see if any of these conflict
with its own write set. If it conflicts, it has to assume the earlier
write set succeeded and its own failed.  It also has to check the write
set stream and apply only those changes that don't conflict.

As stated before in Postgres-R discussion, this mechanism hinges on
being able to determine which write sets conflict because there is no
explicit "I aborted", only a stream of write sets, and each node has to
accept the non-conflicting ones and reject the conflicting ones.

> I'd also second Mike Mascari's question -- whatever happened to the person 
> working on two-phase commit? Is that likely to be done for 7.4? Did he ever 
> send in a patch?

I have not seen a patch from him, but it is very likely he could have
one for 7.4.  This is why it is good we discuss this now and figure out
where we want to go for 7.4 so we can get started.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073