On Thu, Nov 21, 2019 at 11:08:54PM +0100, Tomas Vondra wrote:
> > I think this more and more seems like some sort of bug in the apply
> > code, not resetting a NULL flag and interpreting the bogus value as
> > a valid pointer. Wouldn't the be the first such bug.
> >
>
> FWIW my hunch is the bug is somewhere in this chunk of code from
> apply_heap_update:
>
> if (found)
> {
> /* Process and store remote tuple in the slot */
> oldctx = MemoryContextSwitchTo(GetPerTupleMemoryContext(estate));
> ExecCopySlot(remoteslot, localslot);
> slot_modify_cstrings(remoteslot, rel, newtup.values, newtup.changed);
> MemoryContextSwitchTo(oldctx);
>
> EvalPlanQualSetSlot(&epqstate, remoteslot);
>
> /* Do the actual update. */
> ExecSimpleRelationUpdate(estate, &epqstate, localslot, remoteslot);
> }
>
> Can you please switch to this fram in the backtrace and:
>
> 1) Print newtup.values and newtup.changed matches, so that we can check
> it contains the tuple I shared before? There should be 8 elements in
> each, with 'values' being values formatted as text, and 'changed' being
> flags which values were updated.
newtup.values
{0x55ac6506b488 "8393", 0x55ac6506b4a8 "Pazderka: O média se povede boj. Kdyby
nás politici milovali, bylo by něco špatně", 0x0, 0x55ac6506b540 "{\"id\":
\"d010d44009e211eab259ac1f6b220ee8\", \"date\": \"2019-11-18\", \"name\":
\"Pazderka: O média se povede boj. Kdyby nás politici milovali, bylo by něco
špatně\", \"image\": \"https://cdn.xsd.cz/resize/c"..., 0x55ac6506b758 "242",
0x55ac6506b778 "2019-11-18", 0x55ac6506b7a0 "2019-11-18 12:50:01.816376",
0x55ac6506b7d8 "t", ...garbage}
newtup.changed
{true, true, false, true, true, true, true, true, false <repeats 1656 times>}
Looks fine here.
> 2) Print remoteslot->tts_tupleDescriptor.
{natts = 8, tdtypeid = 55242, tdtypmod = -1, tdrefcount = 3, constr = 0x7f2103867738, attrs = 0x7f2103868448}
> 3) Print rel->attrmap (should have 8 elements)
Has numbers 0 to 7.
> 4) Print remoteslot->tts_values and remoteslot->tts_isnull (8 elements).
(gdb) p remoteslot->tts_values[0]
$26 = 8393
(gdb) p remoteslot->tts_values[1]
$27 = 94198917676232
(gdb) p remoteslot->tts_values[2]
$28 = 94198917676320
(gdb) p remoteslot->tts_values[3]
$29 = 94198918028352
(gdb) p remoteslot->tts_values[4]
$30 = 242
(gdb) p remoteslot->tts_values[5]
$31 = 7261
(gdb) p remoteslot->tts_values[6]
$32 = 627396601816376
(gdb) p remoteslot->tts_values[7]
$33 = 1
(gdb) p remoteslot->tts_isnull[0]
$36 = false
(gdb) p remoteslot->tts_isnull[1]
$37 = false
(gdb) p remoteslot->tts_isnull[2]
$38 = false
(gdb) p remoteslot->tts_isnull[3]
$39 = false
(gdb) p remoteslot->tts_isnull[4]
$40 = false
(gdb) p remoteslot->tts_isnull[5]
$41 = false
(gdb) p remoteslot->tts_isnull[6]
$42 = false
(gdb) p remoteslot->tts_isnull[7]
$43 = false
Nothing surprising to me here.
regards,
o.
>
> regards
>
> --
> Tomas Vondra http://www.2ndQuadrant.com
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
