Andres Freund writes:
> I guess either using valgrind's gdb server on error, or putting some
> asserts checking the size would be best. I can look into it, but it'll
> not be today likely.
I believe the problem is that DecodeUpdate is not on the same page as the
WAL-writing
Hi,
On 2016-07-20 12:45:04 -0400, Tom Lane wrote:
> I wrote:
> > I've still had no luck reproducing it here, though.
Same here so far.
> Hah --- I take that back. On about the fourth or fifth trial:
Interesting.
> ==00:00:00:34.291 21525== Invalid read of size 1
> ==00:00:00:34.291 21525==
I wrote:
> I've still had no luck reproducing it here, though.
Hah --- I take that back. On about the fourth or fifth trial:
==00:00:00:34.291 21525== Invalid read of size 1
==00:00:00:34.291 21525==at 0x4A08DEC: memcpy (mc_replace_strmem.c:882)
==00:00:00:34.291 21525==by 0x66FA54:
I can't help noticing that the failure rate on skink has gone from
"rare" to "100%" since 3d5b227:
http://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=skink=REL9_4_STABLE
I think we need to put some effort into figuring out what's up there.
Also, this morning curculio showed what might be