Marko Kreen wrote:
There is this tiny matter of replicating schema changes asynchronously,
but I suspect nobody actually cares. Few random points about that:
I'm not sure I follow you - the Sybase 'warm standby' replication of
everything is really
useful for business continuity. The
Hi Marko,
Replication requirements vary widely of course, but DDL support is shared by
such a wide range of use cases it is very difficult to see how any real
solution would fail to include it. This extends to change extraction APIs,
however, defined. The question of what DDL to replicate is
On 5/29/08, Andrew Sullivan [EMAIL PROTECTED] wrote:
On Thu, May 29, 2008 at 12:05:18PM -0700, Robert Hodges wrote:
people are starting to get religion on this issue I would strongly
advocate a parallel effort to put in a change-set extraction API
that would allow construction of
On Thu, May 29, 2008 at 11:05:09PM +0300, Marko Kreen wrote:
There is this tiny matter of replicating schema changes asynchronously,
but I suspect nobody actually cares.
I know that Slony's users call this their number one irritant, so I
have my doubts nobody cares. But maybe nobody cares
On 5/29/08, Andrew Sullivan [EMAIL PROTECTED] wrote:
On Thu, May 29, 2008 at 11:05:09PM +0300, Marko Kreen wrote:
There is this tiny matter of replicating schema changes asynchronously,
but I suspect nobody actually cares.
I know that Slony's users call this their number one irritant, so
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Yeah. The main problem is that unless you do WAL based replication,
you cannot achieve transparency. So you need to pick few use cases
and tailor you solution for them, which gets uninteresting very fast
- user _will_ stumble upon spacial
On Friday 29 September 2006 20:02, Andrew Sullivan wrote:
At the beginning of the month, in
http://archives.postgresql.org/pgsql-hackers/2006-09/msg00453.php,
I said that I'd be willing to try to do any sort of co-ordination,
document writing, c. for a project that might define common back-end
