Re: [HACKERS] Race between SELECT and ALTER TABLE NO INHERIT

Hello, sorry for my late reply.

At Wed, 10 Jan 2018 14:56:49 -0500, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote in <26017(dot)1515614209(at)sss(dot)pgh(dot)pa(dot)us>
> I think that there might be a much simpler solution to this, which
> is to just remove make_inh_translation_list's tests of attinhcount,
> as per attached. Those are really pretty redundant: since we are
> matching by column name, the unique index on pg_attribute already
> guarantees there is at most one matching column. I have a feeling

My thought were restricted to the same behavior as the drop case,
but Tom's solution is also fine for me. I agree to the point that
the colums with the same name in a inheritance tree are safely
assumed to be in a inheritance relationship. (Assuming everything
is consistent.)

At Fri, 12 Jan 2018 15:52:08 -0500, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote in <15881(dot)1515790328(at)sss(dot)pgh(dot)pa(dot)us>
> I wrote:
> > I think that there might be a much simpler solution to this, which
> > is to just remove make_inh_translation_list's tests of attinhcount,
> > as per attached.
>
> I went ahead and pushed that, with an isolation test based on the
> one Horiguchi-san submitted but covering a few related cases.

Thank you for commiting it.

regards,

--
Kyotaro Horiguchi
NTT Open Source Software Center