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 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 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 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
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. This can only occur in rare cases
where very few tuples were w
