On Fri, Mar 29, 2019 at 08:25:10PM +0100, Tomas Vondra wrote:
>On Fri, Mar 29, 2019 at 12:06:26PM -0700, Peter Geoghegan wrote:
>>On Fri, Mar 29, 2019 at 11:20 AM Tomas Vondra
>><tomas.vondra@2ndquadrant.com> wrote:
>>>I've pushed a fix for this. The short version is that the serialized
>>>representation was not respecting memory alignment requirements, which was
>>>causing issues in machines sensitive to this (ia64, sparc, hppa). It's a
>>>blind attempt, as I currently don't have access to any such machine.
>>
>>Looks like gharial still has problems:
>>
>>https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=gharial&dt=2019-03-29%2018%3A30%3A47
>>
>
>Yeah, I saw that :-(
>
>Unfortunately fixing this without access to any ia64/sparc/hppa machine
>will be hard. The only thing I can do is wait for gaur/snapper to report
>the failure with a backtrace.
>
OK, so the second memory-alignment fix I pushed on Saturday seems to
have worked. There's one aspect of it that I don't like though - the
MCV is first serialized into a buffer, which is then copied into the
varlena buffer. Deserialization works in reverse, i.e. it copies the
data from the varlena, then accessed the copy.
For the emergency fix that seemed acceptable, as it somewhat reduced the
amount of modified code, but I don't want to leave it like that because
of efficiency and memory consumption. So barring objections I'll push
the attached patch, which ensures proper memory alignment within the raw
varlena buffer. Thus the copies are not needed.
(The second part of the patch merely adds some alignment-enforcing
asserts - I don't plan to commit that, but if someone plans decides to
test this, it might be useful.)
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services