Re: [sqlsmith] Failed assertion in joinrels.c
От | Dilip Kumar |
---|---|
Тема | Re: [sqlsmith] Failed assertion in joinrels.c |
Дата | |
Msg-id | CAFiTN-sL+TLhf3e8pnT27i2qAHAGUbRhQf3_kXeS2UED6wp9mg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [sqlsmith] Failed assertion in joinrels.c (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [sqlsmith] Failed assertion in joinrels.c
|
Список | pgsql-hackers |
On Thu, Sep 8, 2016 at 7:21 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > We could make it work like that without breaking the ABI if we were > to add a NOERROR bit to the allowed "flags". However, after looking > around a bit I'm no longer convinced what I said above is a good idea. > In particular, if we put the responsibility of reporting the error on > callers then we'll lose the ability to distinguish "no such pg_type OID" > from "type exists but it's only a shell". So I'm now thinking it's okay > to promote lookup_type_cache's elog to a full ereport, especially since > it's already using ereport for some of the related error cases such as > the shell-type failure. Okay.. > > That still leaves us with what to do for domain_in. A really simple > fix would be to move the InitDomainConstraintRef call before the > getBaseTypeAndTypmod call, because the former fetches the typcache > entry and would then benefit from lookup_type_cache's ereport. > But that seems a bit magic. > > I'm tempted to propose that domain_state_setup start with > > typentry = lookup_type_cache(domainType, TYPECACHE_DOMAIN_INFO); > if (typentry->typtype != TYPTYPE_DOMAIN) > ereport(ERROR, > (errcode(ERRCODE_DATATYPE_MISMATCH), > errmsg("type %s is not a domain", > format_type_be(domainType)))); > > removing the need to verify that after getBaseTypeAndTypmod. Seems like a better option, done it this way.. attaching the modified patch.. > > The cache loading is basically free because InitDomainConstraintRef > would do it anyway; so the extra cost here is only one dynahash search. > You could imagine buying back those cycles by teaching the typcache > to be able to cache the result of getBaseTypeAndTypmod, but I'm doubtful > that we really care. This whole setup sequence only happens once per > query anyway. Agreed. -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
Вложения
В списке pgsql-hackers по дате отправления: