Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit 6292c23

Browse files
committed
Avoid testing tuple visibility without buffer lock in RI_FKey_check().
Despite the argumentation I wrote in commit 7a2fe85, it's unsafe to do this, because in corner cases it's possible for HeapTupleSatisfiesSelf to try to set hint bits on the target tuple; and at least since 8.2 we have required the buffer content lock to be held while setting hint bits. The added regression test exercises one such corner case. Unpatched, it causes an assertion failure in assert-enabled builds, or otherwise would cause a hint bit change in a buffer we don't hold lock on, which given the right race condition could result in checksum failures or other data consistency problems. The odds of a problem in the field are probably pretty small, but nonetheless back-patch to all supported branches. Report: <19391.1477244876@sss.pgh.pa.us>
1 parent eade082 commit 6292c23

File tree

3 files changed

+54
-12
lines changed

3 files changed

+54
-12
lines changed

src/backend/utils/adt/ri_triggers.c

+10-12
Original file line numberDiff line numberDiff line change
@@ -44,6 +44,7 @@
4444
#include "parser/parse_coerce.h"
4545
#include "parser/parse_relation.h"
4646
#include "miscadmin.h"
47+
#include "storage/bufmgr.h"
4748
#include "utils/acl.h"
4849
#include "utils/builtins.h"
4950
#include "utils/fmgroids.h"
@@ -286,20 +287,17 @@ RI_FKey_check(TriggerData *trigdata)
286287
* We should not even consider checking the row if it is no longer valid,
287288
* since it was either deleted (so the deferred check should be skipped)
288289
* or updated (in which case only the latest version of the row should be
289-
* checked). Test its liveness according to SnapshotSelf.
290-
*
291-
* NOTE: The normal coding rule is that one must acquire the buffer
292-
* content lock to call HeapTupleSatisfiesVisibility. We can skip that
293-
* here because we know that AfterTriggerExecute just fetched the tuple
294-
* successfully, so there cannot be a VACUUM compaction in progress on the
295-
* page (either heap_fetch would have waited for the VACUUM, or the
296-
* VACUUM's LockBufferForCleanup would be waiting for us to drop pin). And
297-
* since this is a row inserted by our open transaction, no one else can
298-
* be entitled to change its xmin/xmax.
299-
*/
300-
Assert(new_row_buf != InvalidBuffer);
290+
* checked). Test its liveness according to SnapshotSelf. We need pin
291+
* and lock on the buffer to call HeapTupleSatisfiesVisibility. Caller
292+
* should be holding pin, but not lock.
293+
*/
294+
LockBuffer(new_row_buf, BUFFER_LOCK_SHARE);
301295
if (!HeapTupleSatisfiesVisibility(new_row, SnapshotSelf, new_row_buf))
296+
{
297+
LockBuffer(new_row_buf, BUFFER_LOCK_UNLOCK);
302298
return PointerGetDatum(NULL);
299+
}
300+
LockBuffer(new_row_buf, BUFFER_LOCK_UNLOCK);
303301

304302
/*
305303
* Get the relation descriptors of the FK and PK tables.

src/test/regress/expected/foreign_key.out

+21
Original file line numberDiff line numberDiff line change
@@ -1381,3 +1381,24 @@ explain (costs off) delete from t1 where a = 1;
13811381
(10 rows)
13821382

13831383
delete from t1 where a = 1;
1384+
--
1385+
-- Test deferred FK check on a tuple deleted by a rolled-back subtransaction
1386+
--
1387+
create table pktable2(f1 int primary key);
1388+
create table fktable2(f1 int references pktable2 deferrable initially deferred);
1389+
insert into pktable2 values(1);
1390+
begin;
1391+
insert into fktable2 values(1);
1392+
savepoint x;
1393+
delete from fktable2;
1394+
rollback to x;
1395+
commit;
1396+
begin;
1397+
insert into fktable2 values(2);
1398+
savepoint x;
1399+
delete from fktable2;
1400+
rollback to x;
1401+
commit; -- fail
1402+
ERROR: insert or update on table "fktable2" violates foreign key constraint "fktable2_f1_fkey"
1403+
DETAIL: Key (f1)=(2) is not present in table "pktable2".
1404+
drop table pktable2, fktable2;

src/test/regress/sql/foreign_key.sql

+23
Original file line numberDiff line numberDiff line change
@@ -1019,3 +1019,26 @@ create rule r1 as on delete to t1 do delete from t2 where t2.b = old.a;
10191019

10201020
explain (costs off) delete from t1 where a = 1;
10211021
delete from t1 where a = 1;
1022+
1023+
--
1024+
-- Test deferred FK check on a tuple deleted by a rolled-back subtransaction
1025+
--
1026+
create table pktable2(f1 int primary key);
1027+
create table fktable2(f1 int references pktable2 deferrable initially deferred);
1028+
insert into pktable2 values(1);
1029+
1030+
begin;
1031+
insert into fktable2 values(1);
1032+
savepoint x;
1033+
delete from fktable2;
1034+
rollback to x;
1035+
commit;
1036+
1037+
begin;
1038+
insert into fktable2 values(2);
1039+
savepoint x;
1040+
delete from fktable2;
1041+
rollback to x;
1042+
commit; -- fail
1043+
1044+
drop table pktable2, fktable2;

0 commit comments

Comments
 (0)