Re: logical changeset generation v4 - Heikki's thoughts about the patch state

On 2013-01-28 16:55:52 -0500, Steve Singer wrote:
> If your using non-surragate /natural primary keys this tends to come up
> occasionally due to data-entry errors or renames.  I'm  looking at this from
> the point of view of what do I need to use this as a source for a production
> replication system with fewer sharp-edges compared to trigger source slony.
> My standard is a bit higher than 'first' version because I intent to use it
> in the version 3.0 of slony not 1.0.  If others feel I'm asking for too much
> they should speak up, maybe I am. Also the way things will fail if someone
> were to try and update a primary key value is pretty nasty (it will leave
> them with inconsistent databases).    We could  install UPDATE triggers to
> try and detect this type of thing but I'd rather see us just log the old
> values so we can use them during replay.

I pushed support for this. I am not yet 100% happy with this due to two
issues:

* it increases the xlog size logged by heap_update by 2 bytes even with wal_level < logical as it uses a variant of
xl_heap_headerthat includes its lenght. Conditionally using xl_heap_header would make the code even harder to read. Is
thatacceptable?
 
* multi_insert should be converted to use xl_heap_header_len as well, instead of using xl_multi_insert_tuple, that
wouldalso reduce the amount of multi-insert specific code in decode.c
 
* both for update and delete we should denote more explicitly that ->oldtuple points to an index tuple, not to an full
tuple

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services