Re: triggers on prepare, commit, rollback... ?

From: Hannu Krosing <hannu(at)krosing(dot)net>
To: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <bruce(at)momjian(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: triggers on prepare, commit, rollback... ?
Date: 2008-05-20 11:50:58
Message-ID: 1211284258.8174.48.camel@huvostro
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 2008-05-20 at 13:36 +0200, Fabien COELHO wrote:

> > or running data modifications through pl/proxy functions where
> > partitioning function always returns two partitions
>
> I don't think that pl/proxy takes care of 2PC semantics in any useful way.
>
> Possibly something like pgpool could take care somehow of the replication
> by executing queries on two backends, but there are issues with such an
> approach (say, a SEQUENCE may not return the same result on both sides,
> some functions may have side effects...), and on commit it must use
> prepared statements on both sides, and I don't think this is the case
> for now with the current pgpool.
>
> Anyway, I do not think that there is a simple high availability / high
> throuput / low latency / guaranteed replication / easy to administrate /
> load balanced silver bullet... My point is more about exploration, and
> for that user-visible hooks would help.

2PC will never be any of ( high throuput / low latency / easy to
administrate )

-------------
Hannu

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Kev 2008-05-20 14:03:16 Re: WITH RECURSIVE patch V0.1
Previous Message Fabien COELHO 2008-05-20 11:36:17 Re: triggers on prepare, commit, rollback... ?