|
17 | 17 | * |
18 | 18 | * Portions Copyright (c) 1996-2006, PostgreSQL Global Development Group |
19 | 19 | * |
20 | | - * $PostgreSQL: pgsql/src/backend/utils/adt/ri_triggers.c,v 1.87 2006/08/21 19:15:29 tgl Exp $ |
| 20 | + * $PostgreSQL: pgsql/src/backend/utils/adt/ri_triggers.c,v 1.88 2006/08/27 21:41:21 tgl Exp $ |
21 | 21 | * |
22 | 22 | * ---------- |
23 | 23 | */ |
@@ -212,9 +212,19 @@ RI_FKey_check(PG_FUNCTION_ARGS) |
212 | 212 | } |
213 | 213 |
|
214 | 214 | /* |
215 | | - * We should not even consider checking the row if it is no longer valid |
216 | | - * since it was either deleted (doesn't matter) or updated (in which case |
217 | | - * it'll be checked with its final values). |
| 215 | + * We should not even consider checking the row if it is no longer valid, |
| 216 | + * since it was either deleted (so the deferred check should be skipped) |
| 217 | + * or updated (in which case only the latest version of the row should |
| 218 | + * be checked). Test its liveness with HeapTupleSatisfiesItself. |
| 219 | + * |
| 220 | + * NOTE: The normal coding rule is that one must acquire the buffer |
| 221 | + * content lock to call HeapTupleSatisfiesFOO. We can skip that here |
| 222 | + * because we know that AfterTriggerExecute just fetched the tuple |
| 223 | + * successfully, so there cannot be a VACUUM compaction in progress |
| 224 | + * on the page (either heap_fetch would have waited for the VACUUM, |
| 225 | + * or the VACUUM's LockBufferForCleanup would be waiting for us to drop |
| 226 | + * pin). And since this is a row inserted by our open transaction, |
| 227 | + * no one else can be entitled to change its xmin/xmax. |
218 | 228 | */ |
219 | 229 | Assert(new_row_buf!=InvalidBuffer); |
220 | 230 | if (!HeapTupleSatisfiesItself(new_row->t_data,new_row_buf)) |
|