[check_postgres] what to do with same_schema behaviour
Cédric Villemain
cedric.villemain at dalibo.com
Wed Dec 16 13:15:27 UTC 2009
Hi,
same_schema action provide usefull output.
But I am in case where I wonder what to do : a table foo on host A have one
column get dropped. Then you start(init) replication to host B.
A et B hosts have same foo table schema, but same_schema action will complain
wrong position for columns between hosts (correct from pg_attribute point of
view, not from real schema).
Ex:
If you drop the column at position 7 then init replication, on host A column 8
keep on position 8, but will be 7 on host B.
This is because pg_attribute keep information on dropped column like this :
select * from pg_attribute where attname like '%pg.dropped.10%';
-[ RECORD 1 ]-+------------------------------
attrelid | 144060
attname | ........pg.dropped.10........
atttypid | 0
attstattarget | 0
attlen | -1
attnum | 7
attndims | 0
attcacheoff | -1
atttypmod | -1
attbyval | f
attstorage | x
attalign | i
attnotnull | f
atthasdef | f
attisdropped | t
attislocal | t
attinhcount | 0
attnum is defined so same_schema will never succes.
So the issue is that schema are the same. I think that same_schema must not
complain in this case.
*But* same_schema should try to reorder by removing droppped column.
Agree ?
--
Cédric Villemain
Administrateur de Base de Données
Cel: +33 (0)6 74 15 56 53
http://dalibo.com - http://dalibo.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : https://mail.endcrypt.com/pipermail/check_postgres/attachments/20091216/72b9c819/attachment.bin
More information about the Check_postgres
mailing list