Re: Feedback on getting rid of VACUUM FULL
| От | Dimitri Fontaine |
|---|---|
| Тема | Re: Feedback on getting rid of VACUUM FULL |
| Дата | |
| Msg-id | m2hbv143yu.fsf@hi-media.com обсуждение |
| Ответ на | Re: Feedback on getting rid of VACUUM FULL (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | pgsql-hackers |
Tom Lane <tgl@sss.pgh.pa.us> 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 по дате отправления: