From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: A note about hash-based catcache invalidations |
Date: | 2011-08-17 17:10:55 |
Message-ID: | 26518.1313601055@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
BTW, while we're thinking about this ...
The plpython patch Jan just submitted reminds me that several of the PLs
detect whether they have obsolete cached data by noting whether the
tuple's xmin *and* TID are the same as previously seen.
Unlike depending on TID alone, I think this is probably safe. It can
obviously give a false positive (thinks tuple changed when it didn't)
after a catalog VACUUM FULL; but an error in that direction is safe.
What would be problematic is a false negative (failure to notice a
real change), and I think the inclusion of the xmin in the test protects
us against that. An example scenario is:
1. We cache the data, saving xmin X1 and TID T1.
2. VACUUM FULL moves the tuple to TID T2.
3. Somebody else updates the tuple, by chance moving it right back to
T1. But they will assign a new xmin X2, so we will know it changed.
Can anyone think of a situation this does not cover?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Charles.McDevitt | 2011-08-17 17:12:45 | Re: non-ipv6 vs hostnames |
Previous Message | Peter Eisentraut | 2011-08-17 17:10:22 | Re: PATCH: Compiling PostgreSQL using ActiveState Python 3.2 |