Peter Geoghegan <pg@bowt.ie> writes:
> Skink's latest run reports a failure that I surmise was caused by this patch:
Yeah, I've just been digging through that. The patch didn't create
the bug, but it allowed valgrind to detect it, because the column
status array is now "just big enough" rather than being always
MaxTupleAttributeNumber entries. To wit, the problem is that the
code in apply_handle_update that computes target_rte->updatedCols
is junk.
The immediate issue is that it fails to apply the remote-to-local
column number mapping, so that it's looking at the wrong colstatus
entries, possibly including entries past the end of the array.
I'm fixing that, but even after that, there's a semantic problem:
LOGICALREP_COLUMN_UNCHANGED is just a weak optimization, cf the code
that sends it, in proto.c around line 480. colstatus will often *not*
be that for columns that were in fact not updated on the remote side.
I wonder whether we need to take steps to improve that.
CC'ing Peter E., as this issue arose with b9c130a1fdf.
regards, tom lane