valgrind errors - Mailing list pgsql-hackers

And lest anyone think Teodor and Oleg are the only ones that have that kind of
problem, here are two in resolve_polymorphic_tupdesc that fire several times
in the regression tests:

==20391== Source and destination overlap in strncpy(0x4BD91DA, 0x4BD91DA, 64)
==20391==    at 0x4026CC4: strncpy (mc_replace_strmem.c:291)
==20391==    by 0x83224CF: namestrcpy (name.c:217)
==20391==    by 0x809635F: TupleDescInitEntry (tupdesc.c:463)
==20391==    by 0x83B2BA1: resolve_polymorphic_tupdesc (funcapi.c:500)
==20391==    by 0x83B272C: internal_get_result_type (funcapi.c:323)
==20391==    by 0x83B256B: get_expr_result_type (funcapi.c:234)
==20391==    by 0x816DE41: addRangeTableEntryForFunction (parse_relation.c:1138)
==20391==    by 0x816023E: transformRangeFunction (parse_clause.c:594)
==20391==    by 0x816059A: transformFromClauseItem (parse_clause.c:709)
==20391==    by 0x815F686: transformFromClause (parse_clause.c:123)
==20391==    by 0x813ADE3: transformSelectStmt (analyze.c:800)
==20391==    by 0x8139B83: transformStmt (analyze.c:183)
==20372== Source and destination overlap in strncpy(0x4BD887D, 0x4BD887D, 64)
==20372==    at 0x4026CC4: strncpy (mc_replace_strmem.c:291)
==20372==    by 0x83224CF: namestrcpy (name.c:217)
==20372==    by 0x809635F: TupleDescInitEntry (tupdesc.c:463)
==20372==    by 0x83B2BEA: resolve_polymorphic_tupdesc (funcapi.c:507)
==20372==    by 0x83B272C: internal_get_result_type (funcapi.c:323)
==20372==    by 0x83B256B: get_expr_result_type (funcapi.c:234)
==20372==    by 0x816DE41: addRangeTableEntryForFunction (parse_relation.c:1138)
==20372==    by 0x816023E: transformRangeFunction (parse_clause.c:594)
==20372==    by 0x816059A: transformFromClauseItem (parse_clause.c:709)
==20372==    by 0x815F686: transformFromClause (parse_clause.c:123)
==20372==    by 0x813ADE3: transformSelectStmt (analyze.c:800)
==20372==    by 0x8139B83: transformStmt (analyze.c:183)

I'm not sure if there are any realistic platforms where strcpy with source and
destination exactly equal is really going to cause an actual problem, but...

And another one in tsearch:

==20349== Source and destination overlap in memcpy(0x71ADAE4, 0x71ADAE4, 8)
==20349==    at 0x4026B12: memcpy (mc_replace_strmem.c:402)
==20349==    by 0x82DC762: dispell_lexize (dict_ispell.c:141)
==20349==    by 0x83B0A66: FunctionCall4 (fmgr.c:1360)
==20349==    by 0x82D315F: LexizeExec (ts_parse.c:208)
==20349==    by 0x82D3776: parsetext (ts_parse.c:399)
==20349==    by 0x82E1EBC: to_tsvector_byid (to_tsany.c:226)
==20349==    by 0x81E9016: ExecMakeFunctionResult (execQual.c:1665)
==20349==    by 0x81E9932: ExecEvalFunc (execQual.c:2097)
==20349==    by 0x81ED49F: ExecEvalExprSwitchContext (execQual.c:4076)
==20349==    by 0x8276D89: evaluate_expr (clauses.c:3841)
==20349==    by 0x82763C0: evaluate_function (clauses.c:3448)
==20349==    by 0x8275EA1: simplify_function (clauses.c:3252)

And i think this is just uninitialized data at the end of the bitfield that is
being masked off anyways:

==20253== Conditional jump or move depends on uninitialised value(s)
==20253==    at 0x82F2C72: array_bitmap_copy (arrayfuncs.c:3854)
==20253==    by 0x82EF4A3: array_set_slice (arrayfuncs.c:2538)
==20253==    by 0x81E6B8C: ExecEvalArrayRef (execQual.c:397)
==20253==    by 0x81EF8D7: ExecTargetList (execQual.c:4988)
==20253==    by 0x81EFDA2: ExecProject (execQual.c:5203)
==20253==    by 0x81EFF1F: ExecScan (execScan.c:143)
==20253==    by 0x8200005: ExecSeqScan (nodeSeqscan.c:131)
==20253==    by 0x81E5F3C: ExecProcNode (execProcnode.c:363)
==20253==    by 0x81E3597: ExecutePlan (execMain.c:1504)
==20253==    by 0x81E16F3: standard_ExecutorRun (execMain.c:309)
==20253==    by 0x81E15A4: ExecutorRun (execMain.c:258)
==20253==    by 0x82CD9E5: ProcessQuery (pquery.c:196)


--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com Ask me about EnterpriseDB's PostGIS support!