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_header that
includes its lenght. Conditionally using xl_heap_header would make the
code even harder to read. Is that acceptable?
* multi_insert should be converted to use xl_heap_header_len as well,
instead of using xl_multi_insert_tuple, that would also 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