Received: from maia.hub.org (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id 34DED6327C9; Thu, 11 Feb 2010 15:35:18 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.208.211]) (amavisd-maia, port 10024) with ESMTP id 11043-10; Thu, 11 Feb 2010 19:34:55 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from spinlock.commandprompt.com (host-215.commandprompt.net [207.173.203.215]) by mail.postgresql.org (Postfix) with ESMTP id 405C26323A4; Thu, 11 Feb 2010 15:35:06 -0400 (AST) Received: from localhost (localhost [127.0.0.1]) by spinlock.commandprompt.com (Postfix) with ESMTP id 61C0C348038; Thu, 11 Feb 2010 11:35:05 -0800 (PST) Received: from spinlock.commandprompt.com ([127.0.0.1]) by localhost (spinlock.commandprompt.com.commandprompt.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dGEhgxZ7p-25; Thu, 11 Feb 2010 11:35:05 -0800 (PST) Received: from perhan.alvh.no-ip.org (190-95-31-230.bk17-dsl.surnet.cl [190.95.31.230]) by spinlock.commandprompt.com (Postfix) with ESMTPSA id B8E61348034; Thu, 11 Feb 2010 11:35:04 -0800 (PST) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id 037666E7EE; Thu, 11 Feb 2010 16:35:01 -0300 (CLST) Date: Thu, 11 Feb 2010 16:35:01 -0300 From: Alvaro Herrera To: Luis Dominguez Cc: santiago@zarate.net.ve, "pgsql-es-ayuda@postgresql.org" , "vepug@postgresql.org" Subject: Re: REF : MIgracion de datos ms sql server 7.0 a Postgresql 8.4 en Linux Message-ID: <20100211193501.GF3145@alvh.no-ip.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.288 tagged_above=-10 required=5 tests=AWL=0.287, BAYES_50=0.001 X-Spam-Level: X-Archive-Number: 201002/200 X-Sequence-Number: 47991 Luis Dominguez escribió: > > > > Buenas tardes, lo que necesitaba exactamente es lo que esta reflejado en el siguente enlace http://mssql-to-postgresql.blogspot.com/2006/04/current-row-version-checking-uses-for.html enviado por el amigo Santiago que le agradezco la ayuda, igual que a los otros companeros de la lista, la confusion se debio a que esta buscado equivalentes entre tipos de datos de ms sqlserver y postgresql y resulta que el xmin es SYSTEM COLUMNS y viene implicito definidos por el sistema claro que de este modo no lo vi. > > ya probramos junto a la gente de sistemas de la organizacion y si sirve esta caracteristica de la columna...' Hmm, esto no me parece algo que sea seguro de usar. ¿Pensaste, por ejemplo, en lo que pasará cuando el contador de transacciones dé la vuelta? Considera que son sólo 32 bits. ¿Y qué pasa si una transacción modifica un mismo registro más de una vez? El XMIN será idéntico pero el registro no es el mismo. (Para solucionar este último problema podrías usar el XMIN junto con el CMIN). Es importante que implementes lógica que permita manejar el wraparound; para esto te recomiendo pg_resetxlog -x como mecanismo de pruebas. (BTW en versiones recientes puedes usar el "xid epoch" para corregir el problema del wraparound). La verdad es que lo de MS parece más seguro que el XMIN por sí solo. Quizás el LSN que inserta o modifica una tupla sería una aproximación más cercana al rowversion. La desventaja es que el LSN no está expuesto al usuario de ninguna forma. -- Alvaro Herrera Vendo parcela en Valdivia: http://www.portalinmobiliario.com/propiedades/fichas.asp?PropID=749682 "Si un desconocido se acerca y te regala un CD de Ubuntu ... Eso es ... Eau de Tux"