On Wed, Oct 17, 2012 at 7:48 PM, Christopher Browne <cbbro...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
