On Thu, Sep 2, 2010 at 11:32 PM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
> I understand what you're after, the idea of being able to set
> synchronization level on a per-transaction basis is cool. But I haven't seen
> a satisfactory design for it. I don't understand how it would work in
> practice. Even though it's cool, having different kinds of standbys
> connected is a more common scenario, and the design needs to accommodate
> that too. I'm all ears if you can sketch a design that can do that.
That design would affect what the standby should reply. If we choose
async/recv/fsync/replay on a per-transaction basis, the standby
should send multiple LSNs and the master needs to decide when
replication has been completed. OTOH, if we choose just sync/async,
the standby has only to send one LSN.
The former seems to be more useful, but triples the number of ACK
from the standby. I'm not sure whether its overhead is ignorable,
especially when the distance between the master and the standby is
very long.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center