On Wed, Oct 17, 2012 at 7:48 PM, Christopher Browne <cbbrowne@gmail.com> wrote:
> Well, replication is arguably a relevant case.
>
> For Slony, the origin/master node never cares about logged changes - that
> data is only processed on replicas. Now, that's certainly a little weaselly
> - the log data (sl_log_*) has got to get read to get to the replica.
Well this is a clever way for Slony to use existing infrastructure to
get data into the WAL. But wouldn't it be more logical for an in-core
system to just annotate the existing records with enough information
to replay them logically? Instead of synthesizing inserts into an
imaginary table containing data that can be extracted to retrieve info
about some other record, just add the info needed to the relevant
record.
The minimum needed for DML afaict is DELETE and UPDATE records need
the primary key of the record being deleted and updated. It might make
sense to include the whole tupledesc or at least key parts of it like
the attlen and atttyp array so that replay can be more robust. But the
logical place for this data, it seems to me, is *in* the update or
insert record that already exists. Otherwise managing logical
standbies will require a whole duplicate set of infrastructure to keep
track of what has and hasn't been replayed. For instance what if an
update record is covered by a checkpoint but the logical record falls
after the checkpoint and the system crashes before writing it out?
--
greg