Thanks to visit codestin.com
Credit goes to postgrespro.com

Re: Feedback on getting rid of VACUUM FULL - Mailing list pgsql-hackers

From Dimitri Fontaine
Subject Re: Feedback on getting rid of VACUUM FULL
Date
Msg-id [email protected]
Whole thread Raw
In response to Re: Feedback on getting rid of VACUUM FULL  (Tom Lane <[email protected]>)
List pgsql-hackers
Tom Lane <[email protected]> writes:
> Completely.  This is a user-visible behavior that we have encouraged
> people to rely on, and for which there is no easy substitute.

Excited to have self-healing tables (against bloat), I parse this as an
opening. Previously on this thread you say:

> (Actually, the ctid is only being used for fast access here; the xmin
> is what is really needed to detect that someone else updated the row.
> But the proposed tuple-mover would break the xmin check too.)

So to have the impossible feature, we need a way not to break existing
code relying on ctid and xmin. How stretching would you consider the
idea of taking a (maybe new) table lock as soon as a SELECT output
contains system columns, this lock preventing the magic utility to
operate?

Regards,
-- 
dim


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Fwd: Copy out wording
Next
From: Bruce Momjian
Date:
Subject: Re: [COMMITTERS] pgsql: CVS NULL Documentation Clearify documentation of CVS's output of