Re: check for interrupts in set_rtable_names
От | Jeff Janes |
---|---|
Тема | Re: check for interrupts in set_rtable_names |
Дата | |
Msg-id | CAMkU=1xgAGXL7z-iqH5JameU4DkqccN_6M7drBqt6Tr9cr+EHA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: check for interrupts in set_rtable_names (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Mon, Nov 16, 2015 at 8:35 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > I wrote: >> I experimented with using a hash table to avoid the O(N^2) behavior. >> This seems to work quite well, and I think it doesn't change the results >> (leastwise, it does not break the regression tests). > > Looking at this again in the light of morning, it occurred to me that it's > pretty broken in the face of long (approaching NAMEDATALEN) input > identifiers. If the de-duplication digits are beyond the NAMEDATALEN > threshold, it would actually get into an infinite loop because hash_search > would ignore them as not part of the key. That can be fixed by truncating > the name appropriately. > > However: actually, this code had a problem already with long identifiers. > What happened before was that it would blithely add digits and thereby > produce an overlength identifier, which indeed looks distinct from the > other ones in the query --- but if we're dumping a view/rule, the > identifier won't be distinct after truncation, which means that > dump/reload could fail, or even worse, silently produce something with > different semantics than intended. > > So the attached updated patch takes care of that problem, not only for > relation names but also for column names. > > I had been leaning towards not back-patching this, but I now feel that > we must back-patch at least the truncation fix, and we probably might as > well back-patch it in toto. Comments? As-committed it has solved the problem, as best as I can tell. Thanks, Jeff
В списке pgsql-hackers по дате отправления: