On Thu, Feb 22, 2018 at 6:32 AM, Robert Haas wrote:
>> Attached patch does this. I cannot recreate this issue locally, but
>> this should still fix it on skink.
>
> Committed.
Looks like it worked.
--
Peter Geoghegan
On Wed, Feb 21, 2018 at 3:18 PM, Peter Geoghegan wrote:
> On Wed, Feb 21, 2018 at 10:55 AM, Peter Geoghegan wrote:
>> Sure, but it looks like it has the exact same underlying cause to the
>> LogicalTapeFreeze() issue. It shouldn't be very hard to write an
>> equivalent patch for LogicalTapeRewind
On Tue, Feb 20, 2018 at 9:34 PM, Andres Freund wrote:
> Doesn't appear to have fixed the problem entirely:
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=skink&dt=2018-02-20%2017%3A10%3A01
>
> relevant excerpt:
> ==12452== Syscall param write(buf) points to uninitialised byte(s)
> ==124
On Wed, Feb 21, 2018 at 10:55 AM, Peter Geoghegan wrote:
> Sure, but it looks like it has the exact same underlying cause to the
> LogicalTapeFreeze() issue. It shouldn't be very hard to write an
> equivalent patch for LogicalTapeRewindForRead() -- I pointed out that
> this could happen there inst
On 2018-02-06 19:25:04 +, Robert Haas wrote:
> Avoid valgrind complaint about write() of uninitalized bytes.
>
> LogicalTapeFreeze() may write out its first block when it is dirty but
> not full, and then immediately read the first block back in from its
> BufFile as a BLCKSZ-width block. Thi