Re: Failed Assert in pgstat_assoc_relation - Mailing list pgsql-hackers
From | Ajin Cherian |
---|---|
Subject | Re: Failed Assert in pgstat_assoc_relation |
Date | |
Msg-id | CAFPTHDa9h2AGeMJ5zmOnmxrnQ9LO-1_BmuAovJ3A=58b-3ThGQ@mail.gmail.com Whole thread Raw |
In response to | Failed Assert in pgstat_assoc_relation (vignesh C <vignesh21@gmail.com>) |
List | pgsql-hackers |
On Mon, Nov 28, 2022 at 8:10 PM vignesh C <vignesh21@gmail.com> wrote: > > Hi, > > While reviewing/testing one of the patches I found the following Assert: > #0 __pthread_kill_implementation (no_tid=0, signo=6, > threadid=139624429171648) at ./nptl/pthread_kill.c:44 > #1 __pthread_kill_internal (signo=6, threadid=139624429171648) at > ./nptl/pthread_kill.c:78 > #2 __GI___pthread_kill (threadid=139624429171648, > signo=signo@entry=6) at ./nptl/pthread_kill.c:89 > #3 0x00007efcda6e3476 in __GI_raise (sig=sig@entry=6) at > ../sysdeps/posix/raise.c:26 > #4 0x00007efcda6c97f3 in __GI_abort () at ./stdlib/abort.c:79 > #5 0x00005590bf283139 in ExceptionalCondition > (conditionName=0x5590bf468170 "rel->pgstat_info->relation == NULL", > fileName=0x5590bf46812b "pgstat_relation.c", lineNumber=143) at > assert.c:66 > #6 0x00005590bf0ce5f8 in pgstat_assoc_relation (rel=0x7efcce996a48) > at pgstat_relation.c:143 > #7 0x00005590beb83046 in initscan (scan=0x5590bfbf4af8, key=0x0, > keep_startblock=false) at heapam.c:343 > #8 0x00005590beb8466f in heap_beginscan (relation=0x7efcce996a48, > snapshot=0x5590bfb5a520, nkeys=0, key=0x0, parallel_scan=0x0, > flags=449) at heapam.c:1223 > #9 0x00005590bf02af39 in table_beginscan (rel=0x7efcce996a48, > snapshot=0x5590bfb5a520, nkeys=0, key=0x0) at > ../../../src/include/access/tableam.h:891 > #10 0x00005590bf02bf8a in DefineQueryRewrite (rulename=0x5590bfb281d0 > "_RETURN", event_relid=16387, event_qual=0x0, event_type=CMD_SELECT, > is_instead=true, replace=false, action=0x5590bfbf4aa8) > at rewriteDefine.c:447 > #11 0x00005590bf02b5ab in DefineRule (stmt=0x5590bfb285c0, > queryString=0x5590bfb277a8 "CREATE RULE \"_RETURN\" AS ON SELECT TO t > DO INSTEAD SELECT * FROM t1;") at rewriteDefine.c:213 > > I could reproduce this issue with the following steps: > create table t1(c int); > BEGIN; > CREATE TABLE t (c int); > SAVEPOINT q; > CREATE RULE "_RETURN" AS ON SELECT TO t DO INSTEAD SELECT * FROM t1; > select * from t; > ROLLBACK TO q; > CREATE RULE "_RETURN" AS ON SELECT TO t DO INSTEAD SELECT * FROM t1; > ROLLBACK; > > Regards, > Vignesh I think what is happening here is that the previous relation is not unlinked when pgstat_init_relation() is called because the relation is now a view and for relations without storage the relation is not unlinked in pgstat_init_relation() void pgstat_init_relation(Relation rel) { char relkind = rel->rd_rel->relkind; /* * We only count stats for relations with storage and partitioned tables */ if (!RELKIND_HAS_STORAGE(relkind) && relkind != RELKIND_PARTITIONED_TABLE) { rel->pgstat_enabled = false; rel->pgstat_info = NULL; return; } There is a logic in DefineQueryRewrite() which converts a relation to a view when you create such a rule like the test case does. So initially the relation had storage, the pgstat_info is linked, then table is converted to a view, but in init, the previous relation is not unlinked but when it tries to link a new relation, the assert fails saying a previous relation is already linked to pgstat_info I have made a small patch with a fix, but I am not sure if this is the right way to fix this. regards, Ajin Cherian Fujitsu Australia
Attachment
pgsql-hackers by date: