hot update doesn't work?
in [PgSql]
|
Prev: [HACKERS] hot update doesn't work?
Next: [COMMITTERS] pgsql: Add PGFILEDESC description to Makefiles for all /contrib
From: Tom Lane on 12 May 2010 11:59 Heikki Linnakangas <heikki.linnakangas(a)enterprisedb.com> writes: > Tom Lane wrote: >> The correct question to ask is whether we could >> vacuum away the older elements of the HOT chain on the grounds that they >> are no longer of interest. What we would see is tuples with xmin equal >> to xmax and cmin different from cmax. The problem then is to determine >> whether there are any live snapshots with curcid between cmin and cmax. >> There is 0 hope of doing that from outside the originating backend. >> Now if heap_page_prune() is being run by the same backend that generated >> the in-doubt tuples, which I will agree is likely in a case like this, >> in principle we could do it. > There's an extra hurdle in the way: If you remove tuples in the middle > of an update chain (not necessarily a HOT update chain), the latest > tuple becomes inaccessible to other transactions running in read > committed mode that might need to find the latest version of the row by > following the ctid pointers. Hm, right. In the normal vacuum case this isn't an issue because all older versions of the row must be dead too, and so there can't be anyone trying to chase up to the chain end from those versions. But a rule such as I suggested above could try to remove tuples whose ancestor is still live (to somebody). regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 12 May 2010 12:02
Merlin Moncure <mmoncure(a)gmail.com> writes: > isn't it possible to skip the snapshot check for temp tables though? No, it's no different from the regular-table case. There could be snapshots that could see the older tuple versions --- consider functions inside queries, etc. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |