Robert Haas wrote: > On Thu, Sep 17, 2009 at 10:21 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> Hannu Krosing <ha...@2ndquadrant.com> writes: >>> On Wed, 2009-09-16 at 21:19 -0400, Tom Lane wrote: >>>> VACUUM FULL CONCURRENTLY is a contradiction in terms. Wishing it were >>>> possible doesn't make it so. >>> It depends on what do you mean by "VACUUM FULL" >> Anything that moves tuples is not acceptable as a hidden background >> operation, because it will break applications that depend on CTID. > > I'm a bit confused. CTIDs change all the time anyway, whenever you > update the table. What could someone possibly be using them for?
As a unique identifier, while you hold a portal open. I recall that last time this was discussed was wrt. HOT. At least one of the drivers used it to implement client-side updateable cursors (ODBC if I recall correctly). We normally guarantee that CTID of a row doesn't change within the same transaction that you read it, but if we do UPDATEs to move tuples behind the application's back, the UPDATEs will cause the CTID of the row to change. It's no different from the situation where another backend UPDATEs the row under your nose, but it's not something you want to do automatically without notice. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
