"Hillel" <hillel 'at' ecommunicate.co.za> writes: > Hi, > > The problem with ctid is > http://www.postgresql.org/docs/8.1/interactive/ddl-system-columns.html > > The physical location of the row version within its table. Note that > although the ctid can be used to locate the row version very quickly, a > row's ctid will change each time it is updated or moved by VACUUM FULL. > Therefore ctid is useless as a long-term row identifier. The OID, or even > better a user-defined serial number, should be used to identify logical > rows. > > Therefore other deletes, updates, or vacuums may have changed the internal > ctid and so the only option is to move away from the deprecated OID to a
You misunderstand the documentation; the documentation only talks about modifications performed by VACUUM FULL, not by DELETE FROM or UPDATE. It even explains that it's bad for long-term row indentification, which we absolutely don't care here. As VACUUM FULL acquires an exclusive lock on the table, which blocks the transactions on that table until finished, this solution works perfectly well. -- Guillaume Cottenceau, MNC Mobile News Channel SA, an Alcatel-Lucent Company Av. de la Gare 10, 1003 Lausanne, Switzerland - direct +41 21 317 50 36
