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! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers