Alvaro Herrera <alvherre@commandprompt.com> writes:
> Tom Lane wrote:
>> 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.
> Actually I think the idea here is to take certain WAL records, translate
> them into "portable" constructs, ship them, and let the slave handle the
> remaining tasks that need to be done with it. For example you would
> only ship heap insert, not index insert; the slave needs to take this
> insert and derive the appropriate index operations that the slave needs.
Oooh, so we'll run user-defined index functions during WAL replay.
Yessir, *that* will be reliable and reproducible.
In any case, you didn't answer the point about heap TIDs not matching
across architectures. That seems at minimum to require that UPDATE
and DELETE identify target tuples by primary key instead of TID.
Which requires for starters that all your tables *have* a primary
key, and for seconds that the replay environment be capable of
identifying the pkey and being able to do lookup operations using it.
Whether or not you'd like to mandate that every table have a pkey,
that certainly takes out any notion that a "WAL" of this species can
be used for crash recovery, because there is 0 chance that it will
work reliably in a crash-corrupted database.
regards, tom lane
