On Mon, Apr 18, 2022 at 12:22 PM Noah Misch <n...@leadboat.com> wrote:
>
> On Mon, Apr 18, 2022 at 10:45:50AM +0900, Masahiko Sawada wrote:
> > On Fri, Apr 15, 2022 at 4:26 PM Noah Misch <n...@leadboat.com> wrote:
> > > On Thu, Apr 07, 2022 at 08:39:58PM +0900, Masahiko Sawada wrote:
> > > > On Thu, Apr 7, 2022 at 7:28 PM Amit Kapila <amit.kapil...@gmail.com>
> > > > wrote:
> > > > > On Thu, Apr 7, 2022 at 8:25 AM Amit Kapila <amit.kapil...@gmail.com>
> > > > > wrote:
> > > > > > I'll take care of this today. I think we can mark the new function
> > > > > > get_column_offset() being introduced by this patch as parallel safe.
> > > > >
> > > > > Pushed.
> > > >
> > > > Thanks!
> > >
> > > I took a closer look at the test case. The "get_column_offset(coltypes)
> > > % 8"
> > > part would have caught the problem only when run on an ALIGNOF_DOUBLE==4
> > > platform. Instead of testing the start of the typalign='d' column, let's
> > > test
> > > the first offset beyond the previous column. The difference between
> > > those two
> > > values depends on ALIGNOF_DOUBLE.
> >
> > Yes, but it could be false positives in some cases. For instance, the
> > column {oid, bool, XLogRecPtr} should be okay on ALIGNOF_DOUBLE == 4
> > and 8 platforms but the new test fails.
>
> I'm happy with that, because the affected author should look for padding-free
> layouts before settling on your example layout. If the padding-free layouts
> are all unacceptable, the author should update the expected sanity_check.out
> to show the one row where the test "fails".
That makes sense.
Regard,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
