-
Notifications
You must be signed in to change notification settings - Fork 673
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DROP SCHEMA fails with "cache lookup failed" #5099
Comments
@SaitTalhaNisanci can you repro this on earlier versions? If that's the case, this becomes a high priority issue. Also, is it only relevant to range distributed tables? Seems related to #3741 |
@onderkalaci it seems to be happening on even 9.5 I think it is mostly about using a composite type so I suspect it will happen with hash distributed tables too, but will check and update here |
I tried with hash tables, and it works fine. I think otherwise we'd have realized such a critical issue earlier |
I am able to reproduce this issue on both hash and range distributed tables. It appears that we try to build CitusTableCacheEntry, and we fail to access the type in this schema that is about to be dropped.
|
I created a small patch to list the objects that are used in the parameters to diff --git a/src/backend/distributed/sql/udfs/citus_drop_trigger/latest.sql b/src/backend/distributed/sql/udfs/citus_drop_trigger/latest.sql
index a440766ed..666dad843 100644
--- a/src/backend/distributed/sql/udfs/citus_drop_trigger/latest.sql
+++ b/src/backend/distributed/sql/udfs/citus_drop_trigger/latest.sql
@@ -11,6 +11,7 @@ BEGIN
FOR v_obj IN SELECT * FROM pg_event_trigger_dropped_objects()
WHERE object_type IN ('table', 'foreign table')
LOOP
+ RAISE NOTICE 'will drop object with [objid=% schema_name=% object_name=%]', v_obj.objid, v_obj.schema_name, v_obj.object_name;
-- first drop the table and metadata on the workers
-- then drop all the shards on the workers
-- finally remove the pg_dist_partition entry on the coordinator
|
#5780 is a duplicate of this. The reason why we don't experience the problem with the range table is that the test example given in this issue doesn't create any shards. CREATE SCHEMA k;
SET search_path to 'k';
CREATE TYPE comp_type AS (
int_field_1 BIGINT,
int_field_2 BIGINT
);
CREATE TABLE range_dist_table_2 (dist_col comp_type);
SELECT create_distributed_table('range_dist_table_2', 'dist_col', 'range');
SELECT count(*) FROM citus_shards WHERE table_name = 'range_dist_table_2'::regclass;
count
-------
0
(1 row) |
the workaround is to drop the table first.
The text was updated successfully, but these errors were encountered: