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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
