Re: Issues with two-server Synch Rep

On Mon, 2010-10-11 at 15:22 -0400, Robert Haas wrote:
> >> This is a completely separate issue from making replication
> >> synchronous. And, really? Useless for running read queries?
> >
> > Absolutely. For a synch standby, you can't tolerate any standby delay
> > at all. This means that anywhere from 1/4 to 3/4 of queries on the
> > standby would be cancelled on any high-traffic OLTP server. Hence,
> > "useless".
>
> What is your source for those numbers? They could be right, but I
> simply don't know.

I was initially taken aback by the word "useless" as well. However, I
had trouble thinking of a use case that isn't better solved by sync rep
without HS, or async rep. I don't have the numbers either though, so
perhaps someone does have a use case.

> It would be far better if we could decouple master cleanup from
> standby cleanup, so that only the machine that actually has the old
> query gets bloated. However, no one seems excited about writing that
> code.

That doesn't seem just a matter of code, it seems like a major design
conflict. If the master removes a tuple and then re-uses that space for
another tuple, you can't move those changes to the standby unless you
cancel queries dependent on the first tuple.

> A further grump about our current architecture is that it doesn't seem
> at all clear how to make it work for partial replication. I have to
> wonder whether we are going down the wrong path completely and need to
> hit the reset button. But neither this nor the pruning problem are
> things that we can reasonably expect the sync rep patch to solve, if
> we want it to get committed this release cycle.

What we have is physical replication, but you seem to be talking about
logical replication (evidence: Slony solves both the independent cleanup
problem and partial replication).

Both logical and physical replication have a place, and I don't believe
either is the "wrong" path. If we'd like to add logical replication, we
may be better of starting with Slony (or Londiste) and working from
there.

Regards,
Jeff Davis