From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, hlinnaka <hlinnaka(at)iki(dot)fi> |
Subject: | Re: SerializeParamList vs machines with strict alignment |
Date: | 2018-09-30 05:14:35 |
Message-ID: | CAA4eK1KTsNC--yPBatOiLJriBfGNgb_vmTF40JcEeZPedcL9YA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Sep 10, 2018 at 7:05 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> writes:
> > On Mon, Sep 10, 2018 at 8:58 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> In particular, SerializeParamList does this:
> >>
> >> /* Write flags. */
> >> memcpy(*start_address, &prm->pflags, sizeof(uint16));
> >> *start_address += sizeof(uint16);
> >>
> >> immediately followed by this:
> >>
> >> datumSerialize(prm->value, prm->isnull, typByVal, typLen,
> >> start_address);
>
> > datumSerialize does this:
>
> > memcpy(*start_address, &header, sizeof(int));
> > *start_address += sizeof(int);
>
> > before calling EOH_flatten_into, so it seems to me it should be 4-byte aligned.
>
> But that doesn't undo the fact that you're now on an odd halfword
> boundary. In the case I observed, EA_flatten_into was trying to
> store an int32 through a pointer whose hex value ended in E, which
> is explained by the "+= sizeof(uint16)".
>
> > Yeah, I think as suggested by you, start_address should be maxaligned.
>
> A localized fix would be for datumSerialize to temporarily palloc the
> space for EOH_flatten_into to write into, and then it could memcpy
> that to whatever random address it'd been passed.
Attached is a patch along these lines, let me know if you have
something else in mind? I have manually verified this with
force_parallel_mode=regress configuration in my development
environment. I don't have access to alignment-sensitive hardware, so
can't test in such an environment. I will see if I can write a test
as well.
> Seems kind of
> inefficient though, especially since you'd likely have to do the same
> thing on the receiving side.
>
I am not sure what exactly you have in mind for receiving side.
datumRestore does below for pass-by-reference values:
/* Pass-by-reference case; copy indicated number of bytes. */
Assert(header > 0);
d = palloc(header);
memcpy(d, *start_address, header);
*start_address += header;
return PointerGetDatum(d);
Do we need any other special handling here?
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
Attachment | Content-Type | Size |
---|---|---|
fix_datum_serialization_v1.patch | application/octet-stream | 714 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2018-09-30 06:23:39 | Re: [HACKERS] [PATCH] Generic type subscripting |
Previous Message | Andrew Gierth | 2018-09-30 03:52:41 | Re: Odd 9.4, 9.3 buildfarm failure on s390x |