Re: A Replication Idea

From: Darren Johnson <darren(at)up(dot)hrcoxmail(dot)com>
To: Orion Henry <orion(at)trustcommerce(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: A Replication Idea
Date: 2002-02-21 04:42:02
Message-ID: 3C747A9A.1080402@up.hrcoxmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


>I've been thinking about replication and wanted to throw out an idea to see
>how fast it gets torn apart. I'm sure the problem can't be this easy but I
>can't think of why.
>
I have some comments/questions to share. If you are proposing SQL based
replication (the statements
get planned, parsed, and executed on all replicas) how can you guarantee
each replica will stay synchronized?
When it comes to executing a set of commands in a transactions, which
could kick off triggers or call
stored procedures, or functions, how does the proxy know each data
change in the transaction was
successful?

While having an advantage of being outside of the core postgres code,
you would not be affected
by constant changes, so development/integration would be less intrusive.
OTOH things like conflict
resolution or avoidance in a multi master scenario are much more
difficult to handle in your proxy
approach.

>
>So, long story short, I'd like to get people's comments on this. If it
>won't/can't work or has been tried before, I want to hear about it before I
>start coding. ;)
>
We did some research a while back, and you might find some of the
information useful within...

http://gborg.postgresql.org/genpage?replication_research

If you're interested, maybe we could collaborate,

Darren

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2002-02-21 04:47:06 Re: Per-database and per-user GUC settings
Previous Message Tatsuo Ishii 2002-02-21 04:04:58 Re: UTF-8 data migration problem in Postgresql 7.2