Hi,
Robert Hodges wrote:
> Part of this is semantics—I like Simon’s logical vs. physical
> terminology because it distinguishes neatly between replication that
> copies implementation down to OIDs etc. and replication that copies data
> content including schema changes but not implementation.
So far, these terms have mostly caused confusion for me: "logical
replication using WAL shipping", "physical replication, but logical
application"...
As Simon didn't explain in more details, what he has in mind, we all
have our own and quite different interpretations. These terms obviously
haven't helped to clarify the issue until now.
> It seems a
> noble goal get both to work well, as they are quite complementary.
Agreed.
> There are various ways to get information to recapitulate SQL, but
> piggy-backing off WAL record generation has a lot of advantages. You at
> least have the data structures and don’t have to reverse-engineer log
> information on disk. Of the multiple ways to build capable logical
> replication solutions, this seems to involve the least effort.
We even have the real tuple, which is about the closest you can get to
being a "logical representation". Using that clearly requires less
efforts than converting a WAL record back to a logical tuple.
For example, it allows the optimization of sending only differences to
the old tuple for UPDATES, instead of always sending full tuples - see
Postgres-R for a partially working implementation.
> My company is currently heads down building a solution for Oracle based
> on reading REDO log files. It requires a master of Oracle dark arts to
> decode them and is also purely asynchronous.
That sounds pretty challenging. Good luck!
Regards
Markus Wanner