Re: Batch replication ordering (was Re: [GENERAL] 32/64-bit

I saw somewhere on this thread that there is no way to tell when
something is committed. that really doesn't make sense, since postgres
is a MVCC system. Doesn't the versioning automatically supply commit
times?

"Ed L." wrote:
>
> On Monday April 14 2003 12:20, Andrew Sullivan wrote:
> > On Fri, Apr 11, 2003 at 06:34:53PM -0400, Jan Wieck wrote:
> > > A) You apply those changes in the order you read them out of the master
> > > on the slave. This requires that you do it all in one big transaction
> > > on
> > >
> > > B) You read all the changes across all tables, but regroup them into
> > > their correct order and original transaction boundaries for playback on
> > >
> > > B2) You read all the changes across all tables simultaneously via
> > > cursors. Worst case you need as many cursors as you have tables and
> > > it's
> >
> > What I am confused about is why one needs to apply now-superseded
> > transactions on the slave at all. Don't you just want a
> > (serializable, mind) snapshot of the master to be applied to the
> > slave?
>
> I'd say, yes, if the process of creating such a snapshot is not overly
> intensive or lengthy. IMO, this is one potentially significant drawback of
> the dbmirror approach in general. The upside to dbmirror is that its
> pretty straight-forward, works pretty well for certain situations, it's
> open source, and it's free.
>
> I know rserv/erServer are reported to use the snapshot approach. But rserv
> didn't work at all for me without mods and looks very much like an
> abandoned prototype for eRServer. ERServer, its successor, is done in part
> by Vadim M. who if I'm not mistaken did an excellent job with MVCC. But,
> at least as of Feb 28, 2003, eRServer was $10,000 minimum, closed source,
> doesn't replicate DDL either, doesn't release trial versions, and has no
> plans to support Redhat 8.0. For us, that was more than enough incentive
> to investigate the alternatives.
>
> I think that'd be a great improvement for dbmirror, along with DDL
> replication.
>
> Opinions on a better *currently available* option?
>
> Ed
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faqs/FAQ.html