impala-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Armstrong <tarmstr...@cloudera.com>
Subject Re: Backporting error codes
Date Thu, 20 Oct 2016 23:41:44 GMT
FWIW there's no specific reason that we don't allow gaps in the error code.
There was a bug in the generator script that meant it didn't handle them
properly, so I turned that off at one point, but it may not be a very hard
fix to support it.

On Thu, Oct 20, 2016 at 4:39 PM, Sailesh Mukil <sailesh@cloudera.com> wrote:

> Of the given choices, I would choose option 2. Not sure if there's a better
> way. Maybe we could add a "// backported. not used" comment next to each
> unused error code?
>
> On Thu, Oct 20, 2016 at 4:24 PM, Lars Volker <lv@cloudera.com> wrote:
>
> > Compilation fails if they are not: Numeric error codes must start from 0,
> > be in order, and not have any gaps: got 94, expected 91
> >
> > Since I'm backporting a fix it feels dangerous to remove that restriction
> > in the process.
> >
> > On Thu, Oct 20, 2016 at 4:16 PM, Henry Robinson <henry@cloudera.com>
> > wrote:
> >
> > > How about not changing the code? Is there any reason they have to be
> > > gapless?
> > >
> > > On 20 October 2016 at 16:12, Lars Volker <lv@cloudera.com> wrote:
> > >
> > > > When backporting a change that introduced a new error code to an
> older
> > > > version Impala there seem to be two options to prevent gaps in the
> > error
> > > > codes:
> > > >
> > > >
> > > >    - Change the error code number during the backport. This will
> result
> > > in
> > > >    different error codes between versions
> > > >    - Backport all new error codes that have been introduced prior to
> > that
> > > >    change, so that the error code stays the same.
> > > >
> > > > Are there other alternatives? Which way should I go?
> > > >
> > > > Thanks, Lars
> > > >
> > >
> > >
> > >
> > > --
> > > Henry Robinson
> > > Software Engineer
> > > Cloudera
> > > 415-994-6679
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message