Markus Wanner <[EMAIL PROTECTED]> writes:
> Robert Hodges wrote:
>> Could you expand on why logical application of WAL records is impractical in
>> these cases? This is what Oracle does. Moreover once you are into SQL a
>> lot of other use cases immediately become practical, such as large scale
>> master/slave set-ups for read scaling.
> I cannot speak for Tom, but what strikes me as a strange approach here
> is using the WAL for "logical application" of changes. That's because
> the WAL is quite far away from SQL, and thus from a "logical
> representation" of the data. It's rather pretty physical, meaning it's
> bound to a certain Postgres release and CPU architecture.
Right. To take just one example: the value of MAXALIGN affects not only
how many tuples you can put on a heap page (thus changing TIDs of tuples,
which fundamentally breaks most of the current types of WAL records)
but how many tuples you can put on an index page (and thus index page
split decisions, and thereby pretty much every single fact about the
contents of upper btree levels). We need not go into architecture
dependencies that are stronger than that one, though there are many.
As for version independence, who thinks they can WAL-replicate changes
of the system catalogs into a different version with significantly
different system catalogs?
You couldn't even begin to make this work with anything approaching the
current level of semantic detail of WAL entries.
What I think Simon was actually driving at was query-shipping, which is
not my idea of "WAL" at all. It has some usefulness, but also a bunch
of downsides of its very own, mostly centered around reproducibility.
With the current WAL design I have some faith that the slaves reproduce
the contents of the master. With any "logical replication" design that
becomes a faith of the religious kind, because it sure isn't provable.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
