Horton

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

Andres Freund <andres@2ndquadrant.com>

View thread View on postgr.es
From: Andres Freund <andres@2ndquadrant.com>
To: Steve Singer <steve@ssinger.info>
Cc: Heikki Linnakangas <hlinnakangas@vmware.com>, Stephen Frost <sfrost@snowman.net>, Robert Haas <robertmhaas@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Pavan Deolasee <pavan.deolasee@gmail.com>, Phil Sorber <phil@omniti.com>, Josh Berkus <josh@agliodbs.com>, Dimitri Fontaine <dimitri@2ndquadrant.fr>, Jeff Janes <jeff.janes@gmail.com>, Simon Riggs <simon@2ndquadrant.com>, Magnus Hagander <magnus@hagander.net>, Abhijit Menon-Sen <ams@2ndquadrant.com>, Alvaro Herrera <alvherre@2ndquadrant.com>, Bruce Momjian <bruce@momjian.us>, Michael Paquier <michael.paquier@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2013-02-02T21:38:16Z
Lists: pgsql-hackers 
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