From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: check for interrupts in set_rtable_names |
Date: | 2015-11-16 16:35:13 |
Message-ID: | 16068.1447691713@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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?
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
set-rtable-names-speedup-and-truncation-fix.patch | text/x-diff | 8.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Janes | 2015-11-16 17:06:22 | Re: Parallel Seq Scan |
Previous Message | Catalin Iacob | 2015-11-16 16:16:25 | Re: proposal: multiple psql option -c |