Re: Feedback on getting rid of VACUUM FULL
От | Tom Lane |
---|---|
Тема | Re: Feedback on getting rid of VACUUM FULL |
Дата | |
Msg-id | 20055.1253204326@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Feedback on getting rid of VACUUM FULL (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Ответы |
Re: Feedback on getting rid of VACUUM FULL
Re: Feedback on getting rid of VACUUM FULL Re: Feedback on getting rid of VACUUM FULL |
Список | pgsql-hackers |
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes: > Robert Haas wrote: >> On Thu, Sep 17, 2009 at 10:21 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> 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. Or for an update without having to hold a transaction open. We have recommended this type of technique in the past: select ctid, xmin, * from table where id = something; ... allow user to edit the row at his leisure ... update table set ... where id = something and ctid = previous value and xmin = previous value;if rows_updated = 0 then report error ("row was already updated by someone else"); (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.) > 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. Exactly. The application is typically going to throw a "concurrent update" type of error when this happens, and we don't want magic background operations to cause that. regards, tom lane
В списке pgsql-hackers по дате отправления: