Re: check for interrupts in set_rtable_names - Mailing list pgsql-hackers

From Jeff Janes
Subject Re: check for interrupts in set_rtable_names
Date
Msg-id CAMkU=1xgAGXL7z-iqH5JameU4DkqccN_6M7drBqt6Tr9cr+EHA@mail.gmail.com
Whole thread Raw
In response to Re: check for interrupts in set_rtable_names  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Jeff Janes
Date:
Subject: Re: Erroneous cost estimation for nested loop join
Next
From: Robert Haas
Date:
Subject: Re: [PATCH] Refactoring of LWLock tranches