Protect object creation from dropping referenced objects #1854
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
whitehawk
added a commit
that referenced
this pull request
Jul 11, 2025
Problem description:
If an object had been created inside a transaction and it had a dependency on
some other object (like schema, custom data type, etc), and that referenced
object had been dropped from another transaction before the first transaction
had been committed, the new object was broken.
Ex. steps:
```
Session 1: create type test_type as enum ('one', 'two');
Session 1: begin;
Session 1: create table test_table(a test_type);
Session 2: drop type test_type;
Session 1: commit;
Session 1: select * from test_table;
```
gave result:
```
ERROR: cache lookup failed for type 16385 (lsyscache.c:2796)
```
The issue reproduced for all dependencies that are registered in 'pg_depend'.
Root cause:
No protection from stealing the objects that are marked as dependencies in
'pg_depend' before the transaction is committed.
Fix:
Lock the referenced object with AccessShareLock when the dependency is created.
Lock is done only for 'normal' dependencies (which means here 'normal
relationship between separately-created objects', when the dependent object may
be dropped without affecting the referenced object, while the referenced object
may only be dropped with CASCADE, in which case the dependent object is dropped
too) and 'auto' (meaning that the dependent object can be dropped separately
from the referenced object, and should be automatically dropped if the
referenced object is dropped).
After the lock is released, do a recheck of the object's presence and error out
if the object was dropped while we waited for the lock.
(cherry picked from commit 769ddb3)
Changes comparing to the original commit:
- 'plpythonu' language is replaced with 'plpython3u' in the test;
- commands output is updated to comply with 7x in the test.
RekGRpth
previously approved these changes
Jul 16, 2025
|
I have found the following situations:
-- session 1
CREATE ACCESS METHOD heap2 TYPE TABLE HANDLER heap_tableam_handler;
begin;
create table t1 (a int) using heap2;
-- session 2
drop access method heap2;
-- session 1
commit;
select * from t1;
ERROR: cache lookup failed for access method 32789 (relcache.c:1887)
LINE 1: select * from t1;
-- session 1
create table t2 (a int);
create publication tb;
begin;
alter publication tb add table t2 ;
-- session 2
drop publication tb ;
-- session 1
commit;
-- The ref to the publication remained even after the publication was dropped
select * from pg_publication_rel ;
oid | prpubid | prrelid
-------+---------+---------
32797 | 32796 | 32793
(1 row)
-- session 1
CREATE TABLE t3 (
a int,
b int
);
INSERT INTO t3 SELECT i/100, i/500 FROM generate_series(1,1000000) s(i);
CREATE STATISTICS s1 (dependencies) ON a, b FROM t3;
ANALYZE t3;
set optimizer = off;
-- set breakpoint here: https://github.com/arenadata/gpdb/blob/dce3c19324af4cb7337d0afa77902576748e091f/src/backend/utils/cache/relcache.c#L4845
EXPLAIN ANALYZE SELECT * FROM t3 WHERE (a = 1) AND (b = 0);
-- session 2
-- after hit a breakpoint
drop statistics s1;
-- continue execution in session 1
ERROR: cache lookup failed for statistics object 32801 (dependencies.c:655) |
Problem description:
If an object had been created inside a transaction and it had a dependency on
some other object (like schema, custom data type, etc), and that referenced
object had been dropped from another transaction before the first transaction
had been committed, the new object was broken.
Ex. steps:
```
Session 1: create type test_type as enum ('one', 'two');
Session 1: begin;
Session 1: create table test_table(a test_type);
Session 2: drop type test_type;
Session 1: commit;
Session 1: select * from test_table;
```
gave result:
```
ERROR: cache lookup failed for type 16385 (lsyscache.c:2796)
```
The issue reproduced for all dependencies that are registered in 'pg_depend'.
Root cause:
No protection from stealing the objects that are marked as dependencies in
'pg_depend' before the transaction is committed.
Fix:
Lock the referenced object with AccessShareLock when the dependency is created.
Lock is done only for 'normal' dependencies (which means here 'normal
relationship between separately-created objects', when the dependent object may
be dropped without affecting the referenced object, while the referenced object
may only be dropped with CASCADE, in which case the dependent object is dropped
too) and 'auto' (meaning that the dependent object can be dropped separately
from the referenced object, and should be automatically dropped if the
referenced object is dropped).
After the lock is released, do a recheck of the object's presence and error out
if the object was dropped while we waited for the lock.
(cherry picked from commit 769ddb3)
Changes comparing to the original commit:
- 'plpythonu' language is replaced with 'plpython3u' in the test;
- commands output is updated to comply with 7x in the test;
- support for dependencies on access methods and publications is added (they
were not presented in 6x).
Author
Fixed access methods and publications. Regarding issue 3, it is a separate problem. Please open a separate ticket for it. |
KnightMurloc
approved these changes
Aug 12, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Protect object creation from dropping referenced objects (#1854)
Problem description:
If an object had been created inside a transaction and it had a dependency on
some other object (like schema, custom data type, etc), and that referenced
object had been dropped from another transaction before the first transaction
had been committed, the new object was broken.
Ex. steps:
gave result:
The issue reproduced for all dependencies that are registered in 'pg_depend'.
Root cause:
No protection from stealing the objects that are marked as dependencies in
'pg_depend' before the transaction is committed.
Fix:
Lock the referenced object with AccessShareLock when the dependency is created.
Lock is done only for 'normal' dependencies (which means here 'normal
relationship between separately-created objects', when the dependent object may
be dropped without affecting the referenced object, while the referenced object
may only be dropped with CASCADE, in which case the dependent object is dropped
too) and 'auto' (meaning that the dependent object can be dropped separately
from the referenced object, and should be automatically dropped if the
referenced object is dropped).
After the lock is released, do a recheck of the object's presence and error out
if the object was dropped while we waited for the lock.
(cherry picked from commit 769ddb3)
Changes comparing to the original commit:
were not presented in 6x).
DO REBASE