[Tomas Vondra <tv@fuzzy.cz>]

Hi,

On 11/25/2017 02:25 AM, Tom Lane wrote:
> I wrote:
>> For me, this patch fixes the valgrind failures inside generation.c
>> itself, but I still see one more in the test_decoding run: ...
>> Not sure what to make of this: the stack traces make it look unrelated
>> to the GenerationContext changes, but if it's not related, how come
>> skink was passing before that patch went in?
> 
> I've pushed fixes for everything that I could find wrong in generation.c
> (and there was a lot :-().  But I'm still seeing the "invalid read in
> SnapBuildProcessNewCid" failure when I run test_decoding under valgrind.
> Somebody who has more familiarity with the logical decoding stuff than
> I do needs to look into that.
> 
> I tried to narrow down exactly which fetch in SnapBuildProcessNewCid was
> triggering the failure, with the attached patch.  Weirdly, *it does not
> fail* with this.  I have no explanation for that.
> 

I have no explanation for that either. FWIW I don't think this is 
related to the new memory contexts. I can reproduce it on 3bae43c (i.e. 
before the Generation memory context was introduced), and with Slab 
removed from ReorderBuffer.

I wonder if this might be a valgrind issue. I'm not sure which version 
skink is using, but I'm running with valgrind-3.12.0-9.el7_4.x86_64.

BTW I also see these failures in hstore:

==15168== Source and destination overlap in memcpy(0x5d0fed0, 0x5d0fed0, 40)
==15168==    at 0x4C2E00C: memcpy@@GLIBC_2.14 (vg_replace_strmem.c:1018)
==15168==    by 0x15419A06: hstoreUniquePairs (hstore_io.c:343)
==15168==    by 0x15419EE4: hstore_in (hstore_io.c:416)
==15168==    by 0x9ED11A: InputFunctionCall (fmgr.c:1635)
==15168==    by 0x9ED3C2: OidInputFunctionCall (fmgr.c:1738)
==15168==    by 0x6014A2: stringTypeDatum (parse_type.c:641)
==15168==    by 0x5E1ADC: coerce_type (parse_coerce.c:304)
==15168==    by 0x5E17A9: coerce_to_target_type (parse_coerce.c:103)
==15168==    by 0x5EDD6D: transformTypeCast (parse_expr.c:2724)
==15168==    by 0x5E8860: transformExprRecurse (parse_expr.c:203)
==15168==    by 0x5E8601: transformExpr (parse_expr.c:156)
==15168==    by 0x5FCF95: transformTargetEntry (parse_target.c:103)
==15168==    by 0x5FD15D: transformTargetList (parse_target.c:191)
==15168==    by 0x5A5EEC: transformSelectStmt (analyze.c:1214)
==15168==    by 0x5A4453: transformStmt (analyze.c:297)
==15168==    by 0x5A4381: transformOptionalSelectInto (analyze.c:242)
==15168==    by 0x5A423F: transformTopLevelStmt (analyze.c:192)
==15168==    by 0x5A4097: parse_analyze (analyze.c:112)
==15168==    by 0x87E0AF: pg_analyze_and_rewrite (postgres.c:664)
==15168==    by 0x87E6EE: exec_simple_query (postgres.c:1045)

Seems hstoreUniquePairs may call memcpy with the same pointers in some 
cases (which looks a bit dubious). But the code is ancient, so it's 
strange it didn't fail before.

regards
Tomas