Re: SerializeParamList vs machines with strict alignment

On Tue, Oct 2, 2018 at 5:31 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> writes:
> > On Tue, Oct 2, 2018 at 9:49 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> Apparently the only somewhat-modern architecture that is resolutely
> >> unaligned-unfriendly is MIPS.
>
> > It's been a few years now since I worked on that architecture, but
> > Sparc is somewhat-modern and resolutely unaligned-unfriendly. It's
> > just that you can optionally install a trap handler that will do super
> > slow non-atomic misaligned access in software instead of blowing up
> > with SIGBUS. With the Sun toolchain you did that explicitly by
> > building with -misalign (though it's possible that more recent
> > compilers might be doing that without being asked?).
>
> Interesting ... I suppose we'd have seen that on the Sparc critters,
> except that they weren't running with force_parallel_mode = regress
> like chipmunk is.
>
> Now I'm tempted to propose that Amit commit *just* the test case
> and not the fix, and wait a day to see which buildfarm critters fail.
>

Okay, I will take care of that. Are you proposing to commit the test
only on HEAD or in back-branches as well? Ideally committing on HEAD
would serve our purpose.
There is one difference in our tests which I would like to highlight:
fix_datum_serialization_v2:
+EXPLAIN (COSTS OFF) EXECUTE stmt_sel_domain(make_psafe_ad(1,2));
+ QUERY PLAN
+--------------------------------------------------------
+ Gather
+ Workers Planned: 1
+ Single Copy: true
+ -> Seq Scan on tarrdomain
+ Filter: ((c2)::integer[] = '{1,2}'::integer[])
+(5 rows)

fix_datum_serialization_v3
! EXPLAIN (COSTS OFF) EXECUTE pstmt('1', make_some_array(1,2));
! QUERY PLAN
! ------------------------------------------------------------------
! Gather
! Workers Planned: 3
! -> Parallel Seq Scan on foo
! Filter: ((f1 = '1'::text) AND (f2 = '{1,2}'::integer[]))
! (4 rows)

I think if we do Analyze on the table after populating rows, it should
use just one worker and that should be sufficient to hit the case
being discussed. I would like to change the test so that it uses just
one worker.

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com